webrtc DTLS timeout

这段时间协助其它同事开发音乐机器人,遇到如题的BUG,花了好几天才做了个work around方案,现总结如下。

python有个著名的aiortc,aioice等,支撑了python语言开发webrtc方面的应用,我们在开发音乐机器人的时候使用到了该库:https://github.com/aiortc/aiortc,在例子里有个janus的videoroom的demo,可是我们在运行这个demo的时候确遇到了一个问题就是怎么都看不到视频听不到声音,media link quality却是100;打印demo的log出来,也不见任何异常,查了janus log出现以下信息:

[8220206318395062] New selected pair for component 1 in stream 1: 1 <-> remote2

[8220206318395062] Component is connected, starting DTLS handshake...

[8220206318395062] Component state changed for component 1 in stream 1: 4 (ready)

[8220206318395062] DTLSv1_get_timeout: 977

[8220206318395062] DTLSv1_get_timeout: 925

[4290012674097374] >> >> ... and sent 735 of those bytes on the socket

[4290012674097374] ... and read -1 of them from SSL...

[4290012674097374] Initialization not finished yet...

[WARN] [4290012674097374] Missing valid SRTP session (packet arrived too early?), skipping...

[4290012674097374] Looks like DTLS!

[4290012674097374] Written 1500 bytes on the read BIO...

[4290012674097374] ... and read -1 of them from SSL...

[4290012674097374] Initialization not finished yet...

[WARN] [4290012674097374] Missing valid SRTP session (packet arrived too early?), skipping...

[4290012674097374] DTLSv1_get_timeout: 962

[WARN] [4290012674097374] Missing valid SRTP session (packet arrived too early?), skipping...

[WARN] [4290012674097374] Missing valid SRTP session (packet arrived too early?), skipping...

[4290012674097374] DTLSv1_get_timeout: 910

......

[8220206318395062] DTLS timeout on component 1 of stream 1, retransmitting

即DTLS timeout,那么DTLS是个什么概念呢?即我们所有的音视频媒体帧都是通过UDP端口发送的,为了安全需要对这个UDP的链路也做了类似TCP的SSL握手,DTLS就是UDP + TSL,这个信息会在sdp协商的时候指定(m=video 9 UDP/TLS/RTP/SAVPF 97 99 101)。这样在ICE协商完成之后就会启动DTLS握手流程,最终我们的数据会以SCTP的格式传输。关于DTLS的协商有个系列的文章描述得非常详细,现链接如下:

HTTPS 温故知新(三) —— 直观感受 TLS 握手流程(上)

HTTPS 温故知新(三) —— 直观感受 TLS 握手流程(上)

再次抓包分析:

image.png

对比个正常得DTLS握手:

image.png

理论上是,参考RFC5764的定义(https://tools.ietf.org/html/rfc5764):

image.png

即服务器端未能收到ChangCipherSpec和Finished消息,这样类似的问题在aiortc上有好几个issue:

https://github.com/aiortc/aiortc/issues/365

https://github.com/aiortc/aiortc/issues/346

有人通过升级openssl到1.1.1的版本解决了这个问题,但是我们已经是1.1.1d版本了依然还存在这个问题,其实这个问题是DTLS中一个普遍的问题,Mediasoup也出现过这个问题:

https://blog.csdn.net/sinat_17736151/article/details/86439405

https://mediasoup.discourse.group/t/dtls-handshake-failed-with-custom-certificate-when-server-has-non-standard-mtu/1697

可是我按照他们的方法在服务端和客户端都设置了SSL_set_mtu和DTLS_set_link_mtu为1350和1472都没有成功:

image.png

其实这个问题的原因就是在openssl中使用BIO来替代UDP传输协议,这个BIO又分为两种,source/link BIO和filter BIO(见https://www.openssl.org/docs/man1.1.0/man3/bio.html),前者是不支持消息大小超过MTU的,如果我们不修改MTU大小,那么BIO出去的数据一旦超过MTU大小则会在网络层面丢失,而且对端opensssl的BIO也是处理不了的;如果我们使用filter BIO则可以接收、处理和发送超过MTU大小的消息,这样的特性在janus服务中已经实现,我们可以看下janus日志:

[5418194469749675] Looks like DTLS!

[5418194469749675] Written 1500 bytes on the read BIO...

[5418194469749675] ... and read -1 of them from SSL...

[5418194469749675] Initialization not finished yet...

服务器能够发送包含Finished的消息在内的1500个字节,但是因为aiortc没有使用filter BIO去处理数据,导致aiortc侧发送的finished的消息在网络上丢包了,于是janus没有收到finished消息,DTLS握手超时,循环启动握手流程。

总结一下,解决的办法有两个:

  1. 修改证书大小使消息包的大小不超过MTU大小(修改网卡MTU大小无用,因为网络中还有中间节点);

  2. 在aiortc层实现filter BIO

对于第二种方法目前难度较大,因aiortc依赖cryptography(python语言的)库封装c的openssl,但是尚未提供filter BIO的接口,也未实现SSL_set_mtu接口。

对于第一种生成了1024位的证书测试通过,貌似2048和4084位的证书都不行:

自签名证书的命令是:

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:1024 -keyout privateKey.key -out certificate.crt

我们也使用了go语言的webrtc框架,见pion(https://github.com/pion/dtls)的实现,这个dtls的实现完全采用go语言开发,未依赖c语言的openssl实现,所以未出现DTLS timeout这个不太友好的缺陷。最后向这类务实的开发者致敬,让我们在go语言领域非常轻松地开发webrtc的应用。

又翻了下janus_gateway的实现,关于DTLS timeout的处理见:

https://github.com/meetecho/janus-gateway/issues/252

https://github.com/meetecho/janus-gateway/pull/254/commits/58409e86b621641cf8a64dc0c0765466f49d9196

https://mta.openssl.org/pipermail/openssl-users/2015-June/001503.html

https://github.com/aiortc/aiortc/issues/365

https://github.com/aiortc/aiortc/issues/346

你可能感兴趣的:(webrtc DTLS timeout)