实时音视频技术（WebRTC/voip/Linphone/P2P）

  视频社交与语音社交？？？ 
  实时视频（直播）/语音通信。多媒体技术团队在音视频编解码、前后处理、传输等技术；
  在语音社交、视频社交、游戏语音和互动直播等领域，关于在语音视频实时传输中实现低延迟这个议题，已经有不少的文章提出各种方案。绝大部分方案的思路都是“优化”，比如说，优化编码、推流、传输和播放等各个环节。要在实时语音视频传输中获得超低延迟，是不能单靠挖空心思去“优化”的，而是要依靠实时的传输机制。

-- 在2017年，有几类应用是比较火的：
 第一类在大学校园最火的游戏应该是王者荣耀和狼人杀，王者荣耀10人组队实时厮杀、还有语音，狼人杀提供实时视频。
 第二类就是互动直播，主播端把通信直播流发到观众端，同时也可以把观众端拉上麦，实现主播和观众的互动。
 一个完整的语音数据流，从采集到远端播放，需要经过多项处理，包括：回声消除、去噪、编码、网络传输、解码等。

> 开源实时音视频技术WebRTC
-- android WebRTC视频通话？ 实时视频通话  rtp传输时参考spydroid这个开源的视频通话项目。WebRTC在互动直播领域独树一帜。
实时视频通话- https://github.com/592713711/Android-VideoChat
基于RTMP数据传输协议的实时流媒体技术研究（论文全文）- http://www.52im.net/thread-273-1-1.html

-- 推流端的协议有RTMP, WebRTC和基于UDP的私有协议:
  1） RTMP是基于TCP的标准协议，CDN网络普遍支持，也能做到相对比较低的延迟。即构科技的互动直播技术在推流端使用RTMP协议，拉流端兼容三种协议：RTMP，HLS和FLV。HLS协议的延迟比较大，在需要进行连麦互动的场景下，不应该使用HLS协议。
  2） WebRTC的好处在于用户体验好，不需要安装东西，分享一个链接就可以看。但是它有一个缺点，就是WebRTC是Google推的一项技术，除了Google Chrome和Opera支持WebRTC，其他浏览器大部分不支持WebRTC。换一句话说，40%的浏览器支持WebRTC，剩下60%浏览器不支持，所以适用范围就比较局限。然后，在中国国内，WebRTC在Google Chrome上的表现也大打折扣。最后，因为浏览器没有开放核心的能力，所以在浏览器上运行的协议比较难以做到比较低的延迟。
  3） 基于UDP的私有协议十分适合做实时音视频系统，它是面向无连接的，避免了TCP做网络质量控制所需要的开销，能够做到比较低的延迟。但是它也有一个缺点，那就是私有协议的兼容性不好。CDN支持标准的RTMP协议，但是不支持基于UDP的私有协议。为了吸纳UDP的优点，而避免UDP的缺点，即构科技的互动直播技术采用了基于UDP的私有协议作为补充，在有必要的时候用来弥补RTMP协议的不足。比如说，只有在网络环境比较恶劣或者在跨国互通的情况下，才使用基于UDP的私有协议；比如说，只在推流端到媒体服务器这一段才使用基于UDP的私有协议，而从媒体服务器转推流到CDN网络这一段采用RTMP协议，在这两段之间通过把UDP私有协议转换成RTMP协议来进行适配和衔接。这样一来，即构科技的直播方案既拥有超低延迟的优势，又保留了标准协议普遍被CDN网络支持的好处。
 

  WebRTC 包含了一套完整的实时音视频应用的开源解决方案。高清低码视频；回声消除技术：开源的项目有WebRTC和Speex
VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。GIPS在VoIP上，技术业界领先。
  RTP/RTCP协议是流媒体通信的基石。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在WebRTC项目中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模块的数据包后，进行解包操作，最后把负载发送到解码模块。因此，RTP/RTCP 模块在WebRTC通信中发挥非常重要的作用。
  要了解回音消除技术的来龙去脉，不得不提及作为现代通讯技术的理论基础——数字信号处理理论。首先，数字信号处理理论里面有一门重要的分支，叫做自适应信号处理。

  WebRTC 从功能流程上来讲，包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节.
  当各式智能硬件、移动应用以及 Web App 中的许多模块都越来越依赖于音视频技术，实时通信已然成为了所有行业的一大基础设施，不仅仅是在直播、游戏这些泛娱乐行业，更渗透到在线医疗、教育、金融等领域。在不同场景下，推动着人们沟通互动方式的改变。

-- 回音消除技术。丢包补偿技术：
  丢包补偿技术可以分为两类：基于发送端补偿和基于接受端补偿。基于发送端补偿包括前向差错纠正、交织和重传技术；基于接受端补偿包括了多种错误隐蔽算法。
  基于发送端补偿可以分为两类：主动重传（本文不讨论）和被动通道编码。被动通道编码包含传统的前向差错纠正技术（FEC）和基于交织的技术。按照和媒体内容的关系，前向差错纠正包括与媒体无关的方法和利用音频属性的媒体相关方法。

 1.非交互式应用
  对于非交互式的语音应用，比如多点广播，对延时的要求没有音质高。交织是强烈推荐的丢包补偿技术，对于交织后的语音，还要采用合适的错误隐蔽算法。与媒体无关的前向误差纠正技术也适合这种应用。
 2.交互式应用
  交互式的应用比如IP电话、即时通讯应用中的实时语音聊天等，对延时很敏感，因此，交织和与媒体无关的前向误差纠正技术都不适合这种应用。媒体相关的前向误差纠正技术只引入很小的延时和较小的带宽增加，是较好的选择，可以利用低比特率的次要编码器获得丢包补偿效果。另外，还可以采用带有衰减的包重复法等效果较好计算简单的错误隐蔽算法进一步提高音质。
 
  在整个直播或点播过程中，最好有实时统计数据，包括网络类型，机器信息，实时网络状况，帧率，码率，分辨率等。这样可以分析遇到的各种问题，特别是对于直播场景，当网络波动，出现卡顿时，可以为动态调整qos提供依据。
  对于实时音视频直播场景，采用qos策略，动态调整编码参数。包括帧率，码率，分辨率，缓冲区。当直播出现卡顿，采用快降慢升的策略，当网络波动比较厉害，这样可以避免编码参数频繁的来回调整，造成恶性循环。
    
webrtc android；webrtc直播 SIP-over-WebSocket（SIPoWS）
WebRTC最重要的一个特征是它允许native和web app之间的互操作(跨平台)的。很少有人利用这一个特征优势。

WebRTC-Android-Learn- https://github.com/RWebRTC/WebRTC-Android-Learn
WebRTC 的 Android 2 Android 实现- https://blog.csdn.net/youmingyu/article/details/53192714
WebRTC 实现Android点到点互连（含Demo）- https://www.jianshu.com/p/2a760b56e3a9?from=groupmessage

-- webrtc for android
Android端WebRtc+Kurento详解- https://www.jianshu.com/p/c93796a6741b
Android-Webrtc AECM for android- https://github.com/BillHoo/webrtc-based-android-aecm
WebRtc是google开源的视频通话技术，Kurento是Kurento公司开源的媒体服务器。两者结合起来可以达到多人视频通话的效果。目前在git上Android端webrtc+Kurento的demo
KurentoRoomAndroid: 官方地址为 https://github.com/nubomedia-vtt/kurento-room-client-android
https://github.com/BaeBae33/webrtc_android

-- WebRTC 的 Android 2 Android 实现- https://blog.csdn.net/youmingyu/article/details/53192714
ProjectRTC是一个WebRTC的PC端项目- https://github.com/pchab/ProjectRTC
AndroidRTC是ProjectRTC的android客户端- https://github.com/pchab/AndroidRTC

-- 信令数据

信令服务器代码：https://github.com/matthewYang92/WebRtcServer（代码改自ProjectRTC）
客户端代码：https://github.com/matthewYang92/WebRtcAndroidClient（代码参考AndroidRTC项目)

 H.264也提供VBR、ABR、CBR、CQ等多种编码模式，各个移动平台兼容性好。
 在实时音视频系统中需要在Web上进行实时通信，各个浏览器都已支持WebRTC，所以WebRTC是Web上实时音视频通信的首选。但WebRTC是基于浏览器的客户端点对点系统，并没有定义多路通信标准和服务中转标准，不管是1V1模式还是1对多模式，需要引入WebRTC网关来接入自定义的实时系统。网关负责将WebRTC的SDP、ICE、STUN/TURN、RTP/RTCP翻译成自定义系统中的对应协议消息，实现无缝对接WebRTC。WebRTC很多类似的开源网关，例如：licode、janus等。
  善于构建高性能服务系统和系统性能调优，喜好解决系统的疑难杂症和debug技术。早年痴迷于P2P通信网络、TCP/IP通信协议栈和鉴权加密技术，曾基于P2P super node技术实现了视频实时传输系统。2015年加入学霸君，负责构建学霸君的智能路由实时音视频传输系统和网络，解决音视频通信的实时性的问题。 近几年专注于存储系统和并发编程，对paxos和raft分布式协议饶有兴趣。尤其喜欢数据库内核和存储引擎，坚持不懈对MySQL/innoDB和WiredTiger的实现和事务处理模型进行探究。热衷于开源，曾为开源社区提过些patch。语音视频传输通道和 IM 的通道是相互独立的。

> Android平台的P2P语音传输技术
Victor Lazzarini，封装了一套 OpenSL ES 的 API.

UPnP框架天生就是为对等网络连接（P2P）的结构设计的。

> Voip
  腾讯无线的VOIP杀手锏产品;VoIP与IPTV（Interactive Personality TV）;Android平台的P2P语音传输技术
  VoIP（Voice over Internet Protocol）即首先数字化语音信号并压缩成帧，转换为IP数据包在网络上传输，以此完成语音通话的业务，是一种利用IP协议传输语音数据的、新兴的通信技术。 既然Phone-Phone和PC-Phone的VoIP属于基础电信业务，没有基础业务牌照的电信业务经营者显然不能从事。QQ、飞信等即时通信软件中的实时语音通话功能其实就是这类VoIP。WhatsApp /Skype采用 VoIP 的技术。微信占据了太多的运营商信令资源.信令方案.微信电话本。
  实时音视频技术是源于早期的VoIP通信.VOIP； mina框架，发现很适合做即时通信后台;VoIP,SIP协议。VOIP通话，SIP通话。BroadVoice （音频编码的），ffmpeg（音视频编解码的）。 VoipSdk（主控模块）;sipdroid，imsdroid(doubango)，linphone，csipsimple（pjsip）。
  VOIP语音编解码技术和网络传输技术;即时语音通话（VoIP）;VOIP通话中媒体流是走的UDP，一旦网络质量不好，语音的质量就会有延时或者断续。
Android 开发 voip/sip 程序- http://blog.csdn.net/huang_rong12/article/details/51252329
android sdk 19 sample代码中的SipDemo的例子-  http://download.csdn.net/detail/huang_rong12/9504286 

在android 2.3以后提供的api中是用sip表示voip相关接口的。

used in many data communication protocols- https://github.com/Jhuster/TLV
PigeonCall：一款Android VoIP网络电话App架构分析- http://blog.51cto.com/ticktick/1746136
If you need VoIP but not SIP, check out WebRTC- http://www.webrtc.org/

voip的意思是网络电话，会话发起协议（SIP）是建立VOIP连接的IETF标准。BroadVoice （音频编码的），ffmpeg（音视频编解码的）;微信的语音通话、SKYPE，技术上就是VoIP。另外，运营商的VoLTE业务，技术上也是VoIP。
  好用的是linphone 和csipsimple，linphone的最大优势在于全平台支持，android，ios，winphone，windows，linux，mac osx，web 全都支持，但是质量上还是欠火候，改过他的库，添加过g.729的支持，他的c 代码，命名和缩进都觉得乱。
 https://git.oschina.net/zencodex/CSipSimple

> Linphone
   研究实时语音通话，基于ilbc的编解码；ilbc的编解码压缩比率还是比较大的，大概在1/10至1/9之间。也就是说假如每秒20kb的语音数据，编码后就2kb/s，非常小，非常利于网络传输；
    speex（http://www.speex.org）有回声消除模块。speex是一个c库（当然也有Java版本的，http://code.google.com/p/speexdroid/，但我还是建议使用c库，因为java版本的speex效率可能不是很高），因此我们需要用到jni。如果没有使用过jni的话，这也是一个学习的机会。可以参考sipdroid http://code.google.com/p/sipdroid/ 如果还是觉得麻烦的话可以参考这个开源项目 http://code.google.com/p/android-recorder/
    建议用rtp实现语音传输jlibrtp库- http://sourceforge.net/projects/jlibrtp/?source=directory，这是一个java版本的实现。不过，这个库有丢包的问题，以及会抛库内的一些异常。由于我没有找到更好的RTP传输的库，所以只好使用这个库了。喜欢研究的同学也可以研究一下Sipdroid的RTP实现。

-- xmpp 与 mqtt
  1、xmpp比较重型，如果用于移动客户端开发，会比较占资源，且网络不稳定时表现比较差，但比较成熟，国内资料相对较多，而且有一个很成熟的开源的解决方案了，那就是Openfire，自己百度下，这方面的资料挺充足的。
  2、mqtt比较轻型，适用于客户端开发，且资源占用没那么多，这个东西是ibm用来做医疗设备监控的，可以说是为嵌入式系统准备的。但是国内的资料很少，要做好被英语蹂躏的准备。

音视频即时通讯（Android)- http://download.csdn.net/detail/fanxiaojun66/4565705
Android实现实时视频通话或监控方案- http://blog.csdn.net/ericfantastic/article/details/50234239
Linphone官网- http://www.linphone.org/technical-corner/linphone/downloads
linphone- android- git://git.linphone.org/linphone-android.git
  Linphone是一款基于标准SIP的开源VoIP电话工具，是一款遵循GPL的开源的网络视频电话系统。它能够让你通过internet来查询朋友的IP，并通过IP给他打电话的软件，功能非常强大，既支持桌面系统，也支持移动终端，还能支持WEB浏览器。使用linphone，我们可以在互联网上随意的通信，通过语音、视频、即时文本消息。

-- LinePhone的核心功能：
 符合RFC3261协议的SIP user agent；
 SIP/UDP, SIP/TCP, SIP/TLS；
 支持IPv6；
 Digest authentication；
 支持多个电话同时通话的呼叫管理功能：hold on with music, resume, transfer…；
 多种SIP代理支持：registrar, proxies, outbound proxies；
 即时文本消息的送达通知；
 SIMPLE标准的对等（P2P）模式；
 DTMF (telephone tones)支持 SIP INFO or RFC2833；
 音频Codec支持： speex (narrow band and wideband), G711 (ulaw,alaw), GSM, G722. 通过插件的方式也支持 AMR-NB, SILK, G729 and iLBC；
 视频Codec支持：VP8 (WebM), H263, H263-1998, MPEG4, theora and H264 (thanks to a plugin based on x264), 支持的分辨率从QCIF(176x144)  到 SVGA(800x600) 提供足够的CPU Power以及保证网络带宽；
 音频会议；
 支持SRTP和zRTP（音视频加密）；
 ICE支持（RFC5246）允许无relay server的对等（P2P）音视频连接；
 支持任何一款Linux系统下的V4L和V4L2的WebCam以及Windows的Directshow；
 声学回音消除使用伟大的回音消除器libspeexdsp（SPEEX，当然不仅使用SPEEX Codec）；
 高效的带宽管理机制：带宽限制的信号使用SDP（b＝AS…），从而在音频和视频比特率符合用户的网络能力建立的会话；
 低带宽模式：audio calls over EDGE；
 自适应音频和视频码率算法适应可用的网络带宽；