Browsed by
Tag: srtp

计算 IV

计算 IV

在 SRTP 对负荷进行加密（或者解密）时需要先计算 IV （Initialization vector, 初始化向量），RFC3711定义了该值的计算方法：

IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)

看起来似乎很普通、也很容易理解，无非就是三个参数的异或计算：（1）k_s，（2）SSRC 以及（3）i。

IV 是 16 字节的数据流；k_s 是 session salt（大小14字节），要求左移2字节；SSRC 是 RTP 中的源标识参数，要求左移8字节。

i 参数有点特殊，定义为「包索引」，它是 48 比特的值，规范中定义如下：

i = 2^16 * ROC + SEQ.

ROC 是 rollover counter， RTP 包中没有这个参数，需要根据 SEQ 的值来判断是否需要设置 ROC。这里提一下， RTP 协议非常山炮地用 2 字节定义 SEQ 值，可想而知它完全不够用。因此应用层不得不自己计算ROC值，组合 ROC 值和 SEQ 值 才能完整判断 RTP 包的真实序列号。

组合出三个 16 字节的数据流后，异或计算得出 IV 值，请参考以下图表示意：

IV 异或计算

从图中也可以看出，IV 虽然有 16 个字节，但是实际上最后两个字节根本没用，因此默认设置为 0 即可。

roc + seq 的设置可以取巧一下。虽然完整定义是 48-bits，但用32-bits也足够了（考虑到 VoIP 对话中一般 20ms 一个包，序列号要溢出32bits的值需要超过990天）。而简化成 32-bits 的最大好处就是直接调用 C 函数（htonl）进行网络字节序转换即可，只需要填充第10个字节到第13个字节。

SSRC 是 32-bits 整数，因此也需要转换成网络字节序；而 session salt 本身是 14 字节的数据流，无需转换字节序。

为什么放弃了webRTC？

为什么放弃了webRTC？

首先必须要说明的是：webRTC是非常好的技术，以至于我现在仍然在怀疑，放弃webRTC是不是个明智的决定，内心依然是忐忑不安。

然而现状就是将webRTC从MSS新版本中砍掉了。下面试图说明清楚做决定时的一些考虑。

从webRTC技术的发展脉络看，感觉ta更适合于公共网络的通信，尤其是越来越像专为google hangouts服务。由于是服务于公共网络，因此“加密”提高到一个非常重要的位置，几乎达到了神经质的地步。webRTC设计之初就没有考虑过传统的VoIP网络（尽管该技术来自于收购的GIPS团队，而该团队本身就是为VoIP网络开发出身的），从传输到业务，基本都特立独行。当然，这没什么不好，只是由于与传统VoIP网络切割开来，实在让人经常感到惋惜。

既然没有考虑传统VoIP网络，当然就更不可能考虑网络部署的多样性。全方位加密固然让自己显得安全，带来心理上的安慰，但也增加了网络部署的复杂性（VoIP本身已经够复杂了）。就一般的VoIP应用而言，“salt+MD5”以及SRTP已经足够保证通信的安全性和私密性。而最新的webRTC（不特别说明的话，这里我们总是指Chrome的webRTC实现）要求getUserMedia等操作必须是来自加密（HTTPS）的网站，websocket也必须进行加密。这也就是说，用户必须要为webRTC服务器（通常也是呼叫服务器或者IPPBX）部署单独的签名加密（TLS或者SSL）。对于提供公众服务的网站而言，部署TLS/SSL不是太大问题，而要求中小企业申请签名并部署在呼叫服务器中，这毫无疑问极大地增加了系统的复杂度，增加了部署难度，而且这样做的意义又有多大了？在企业通信网络里与其这样增加复杂度（网络复杂度和管理复杂度），还不如干脆直接建立VPN网络，方案很成熟，加密更全面，保护更周到，方式方法也简单得多。

这就是我们感觉webRTC只适合公众网络并且已经神经质的原因之一。何况，“加密”有时候更多的是个管理问题而不是技术问题。

webRTC另一个宏大的目标是提供各平台统一的用户体验。愿望是很美好的，但是是否能实现值得商榷。把所有的处理都放入浏览器，固然增加了可移植性，但最大的问题也就是牺牲了平台的独特性和高效性。比如在移动平台，webRTC的耗电量就明显偏高。而且在移动平台各种莫名其妙的设定，极大地损害了用户体验，比如播放ring-back tone，居然要求用户必须点击一个按钮才能继续（是我out了么？），这实在是太扯了。

而最被我们诟病的是兼容性。webRTC基本没有什么兼容性可言。按道理已经发布这么久了，多少应该在一些关键点上考虑一下兼容性，然而并没有。这对一个像google hangouts这样的网站来说，不是大问题，用户无非升级一下chrome好了。而对部署在许许多多用户voip网络中的PBX或者webRTC服务器而言，就是噩梦了。用户升级了Chrome，就必须同时升级服务器，如果不升级服务器，就必须降级Chrome。与之相比，microsoft对兼容性的考虑简直贴心贴肺。

这种对兼容性的唾弃有时候甚至直接表现在产品本身。比如当初的Gtalk，直接就放弃了，我们花费大量时间精力对接Gtalk，最后也是然并卵。对webRTC也会产生同样的顾虑。

webRTC当然有很多非常优秀的技术特点，比如源自GIPS的回音消除技术、超强的语音编解码技术等。思虑再三，决定还是不再跟随，砍了算了，以后再说吧。