一、概述

  本文主旨是记录医疗探视分机对接智慧医疗平台过程中出现诸多视频异常问题，例如：黑屏、卡顿等。通过记录这些问题的处理过程，为后期开发遇到类似问题提供参考依据。

二、背景

  医疗探视分机是门口机在医疗领域的一种实际应用，其主要业务是和其他分机以及护士站主机等设备进行视频通话。但这种通话高度依赖于固定的设备，因此它的应用场景很大程度受到限制，例如很多病患亲属希望能够直接使用手机和对患者进行远程探视。针对用户无法使用手机或电脑实现远程探视的痛点，本项目将对接智慧医疗平台以满足客户的实际述求。

三、技术分析

  设备端之间的会话是基于私有SIP建立，而对接智慧医疗平台需要采用标准SIP，在此过程中需要完成双方的相互兼容问题。设备端作为UA需要注册到平台SIP服务器中，SIP服务会为UA分配号码，web端拨打该号码能够呼叫到设备端。
  服务端SIP服务器采用开源组件freeSWICH，音视频数据源是转发webRTC数据。设备端SIP服务由yate开源库提供，音视频的编解码由设备端内置DSP完成。

四、异常问题处理

4.1 双方视频显示黑屏

（1）问题描述

  探视分机注册到智慧医疗平台服务器后，由平台web端的UA发起呼叫，接通后双发能够正常语音通话，但是视频通话时则只有语音没有视频画面。

（2）问题分析

• 日志分析
    分析设备串口日志发现dsp实践上并未进行解码，应用层未将数据下发给dsp进行解析。可以排除时dsp解码问题导致黑屏。
• 抓包分析
  VOIP通信部分数据如下：

|Time     | 10.42.1.6                             |
|         |                   | 10.7.115.99       |
|5.133284 |         INVITE SDP                    |
|         |(25060)  ------------------>  (5060)   |
|5.164983 |         100 Trying|                   |
|         |(25060)  <------------------  (5060)   |
|5.268929 |         180 Ringing SDP (g711U )      |
|         |(25060)  <------------------  (5060)   |
|5.293043 |         RTP (g711U)                   |
|         |(28696)  <------------------  (9654)   |
|6.679924 |         200 OK SDP (g711U H264)       |
|         |(25060)  <------------------  (5060)   |
|6.683721 |         ACK       |                   |
|         |(25060)  ------------------>  (5060)   |
|6.714187 |         RTP (g711U)                   |
|         |(28696)  <------------------  (9654)   |
|9.329582 |         RTP (g711U)                   |
|         |(28696)  ------------------>  (9654)   |

  通过分析上面的流程数据，可以看出在主叫和被叫建立会话后，双方的音频RTP通道正常，但视频RTP通道异常（无数据）。这就说明通信双方在进行媒体数据协商（SDP）过程中双方没有达成一致，导致没有建立数据RTP视频数据通道。

分析主叫（医疗平台）的SDP报文：

v=0
o=FreeSWITCH 1625189141 1625189142 IN IP4 10.42.1.6
s=FreeSWITCH
c=IN IP4 10.42.1.6
t=0 0
m=audio 28696 RTP/AVP 102 9 0 8 104 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:104 telephone-event/48000
a=fmtp:104 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 27246 RTP/AVP 103
b=AS:3072
a=rtpmap:103 H264/90000
a=fmtp:103 profile-level-id=420028;max-br=1024;max-mbps=491520;max-fs=8192
a=rtcp-fb:103 ccm fir
a=rtcp-fb:103 ccm tmmbr
a=rtcp-fb:103 nack
a=rtcp-fb:103 nack pli

再看下被叫（门口机）

v=0
o=F53968484 0 0 IN IP4 10.7.115.99
s=Talk session
c=IN IP4 10.7.115.99
t=0 0
a=doorFloor:1
a=responseType:0
a=doorType:0
a=isSpecialType:0
a=isConfirm:0
a=version:V2.0.0
a=lockNum:1
a=isCall:1
m=audio 9654 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
m=video 9856 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801F;packetization-mode=1
a=sendrecv

  对比发现进行视频协商时出的问题，RTP Payload Type（有效负载类型）不匹配，有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的。实际RTP Payload Type数据对比如下：

m=video 27246 RTP/AVP 103 //医疗平台默认的视频PT值
m=video 9856 RTP/AVP 96  //门口机平台回复的视频PT值

(3) 问题解决

  由于双方Payload Type值不同，导致设备端都认为对方不支持己方的视频格式，RTP数据通道未传输视频数据。根据RFC3551文档中规定，视频编码为H264其PT为动态值，范围时96-127，但业界一般H264的PT值为96。经过和平台同时沟通最后达成一致，由平台进行PT值兼容处理。

4.2 设备端视频画面卡住

（1）问题描述

  在解决上述问题后设备端可以收到平台下发的视频数据，但是画面总是定格无法正常播放。通过网络抓包没有发现数据丢包情况，但是dsp解析出现保存。

（2）问题分析

• 1、平台开发人员保存网络数据中的H264裸码流，使用工具可正常播放。
• 2、保存RTP数据包给dsp开发进行解析，解析后的数据提取H264裸码流，工具无法正常播放，使用视频数据分析工具发现数据中存在大量错误。
• 3、平台转发的webrtp数据本身是没问题的，有问题的应该是RTP数据包异常，导致dsp解析RTP数据包错误，进而引起解析出的H264视频数据有问题。
• 4、使用tcpdump抓包分析发现

(3) 问题解决

通过上述分析发现平台通过webRTC转发的RTP数据中SPS和PPS在一个数据包中，它们包含了初始化H.264解码器所需要的信息参数，包括编码所用的profile，level，图像的宽和高，deblock滤波器等。但是设备端DSP目前还不支持SPS和PPS在一个数据包，从而无法获取正常的图像参数，最终导致到部分RTP数据包解码失败，引发视频卡住问题。最终经过沟通，由DSP进行SPS和PPS同包解析处理。

4.3 设备端视频不流畅

（1）问题描述

  经过上上述问题的处理，探视分机和医疗平台能够进行视频通话，但是通话的过程中视频卡顿现象十分严重。

（2）问题分析

• 查看串口日志
  串口打印显示应用出现大量RTP丢包打印，导致dsp解析RTP数据包时出现大量丢帧现象。
• 抓包分析

Max delta = 962.23 ms at packet no. 1486 
Max jitter = 4.62 ms. Mean jitter = 3.05 ms.
Max skew = -25.43 ms.
Total RTP packets = 5751   (expected 5751)   Lost RTP packets = 38 (0.66%)   Sequence errors = 1807 
Duration 62.45 s (-54068 ms clock drift, corresponding to 12082 Hz (-86.58%)

  通过分析上面的数据可以看出实际网络中RTP丢包并不严重，丢包率约0.66%，但乱序比例却高达31%。RTP包乱序将直接导致DSP数据解析失败，从而引起视频卡顿花屏等情况。
  RTP的底层的传输协议是UDP协议，缺少重传和排序等机制，传输时不能保障数据达到以及报文的顺序。门口机设备使用私有SIP，网络环境相对简单，RTP包发送速率较慢，所以一般是很少出现乱序情况。
  智慧医疗平台的视频是转发的webrtc的视频流数据，数据发送速率较高（发送速率约90包/s），此导致设备端接收到的包是乱序的概率大大提高。门口机SIP服务使用的开源库yate5中并没有实现对视频的去抖动处理，因此需要单独实现该功能。

(3) 问题解决

  对于RTP乱序的问题，通常的做法是需要接受端做视频接收子模块VRX提供缓冲区
来进行去抖动处理。

网络包一般分为三种情况分析：

• 1、丢包：对于丢包的情况，jitterbuffer也是无解的；
• 2、乱序：jitterbuffer能够处理，但超时和超buffer缓存大小时也会丢弃；
• 3、延时：jitterbuffer能够处理，但超时和超buffer缓存大小时也会丢弃；

  总体处理思路如下图所示，图中可以看到设备端获取到的网络数据已经出现了乱序和超时情况，对于这种情况需要增加一个线程进行dejiiter处理，处理后的数据顺序恢复正常。

  以单生产者者消费者为问题处理模型，生产者负责从网络中接受数据并放入缓存，消费者负责将缓存中的数据进行排序处理后下发给DSP解析解码。基本流程如下：

• 1、 RTP接受线程（生产者）从网络中读取RTP数据，并将数据存储到链表buffer中；
• 2、Dejiiter线程（消费者）对链表中的数据进行排序，排序规则是：链表轮询并和当前数据序号进行比较，序列号大的加到链表后面，序列号小的插入到链表前面；
• 3、超时到达的数据无论是乱序的还是顺序的都会作为丢弃帧进行处理，防止后续数据阻塞。
  PS：jitterbuffer实际上是把数据缓存处理后发给解码器进行解码的，其必然会有一定延时。

五、问题总结和反思

  对接医疗平台过程中出现了很多问题，本文列举几个比较典型的错误进行记录，这些错误产生的原因通常是由于双发的差异导致。今后对接类似平台时首先需要明确双发之间的差异，对可能存在的问题提前进行预判，避免问题产生后投入大量精力进行排查。下面列举了几个典型问题可供参考：