視訊社交與語音社交？？？ 
  實時視訊（直播）/語音通訊。多媒體技術團隊在音視訊編解碼、前後處理、傳輸等技術；
  在語音社交、視訊社交、遊戲語音和互動直播等領域，關於在語音視訊實時傳輸中實現低延遲這個議題，已經有不少的文章提出各種方案。絕大部分方案的思路都是“優化”，比如說，優化編碼、推流、傳輸和播放等各個環節。要在實時語音視訊傳輸中獲得超低延遲，是不能單靠挖空心思去“優化”的，而是要依靠實時的傳輸機制。

-- 在2017年，有幾類應用是比較火的：
 第一類在大學校園最火的遊戲應該是王者榮耀和狼人殺，王者榮耀10人組隊實時廝殺、還有語音，狼人殺提供實時視訊。
 第二類就是互動直播，主播端把通訊直播流發到觀眾端，同時也可以把觀眾端拉上麥，實現主播和觀眾的互動。
 一個完整的語音資料流，從採集到遠端播放，需要經過多項處理，包括：回聲消除、去噪、編碼、網路傳輸、解碼等。

-- 推流端的協議有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

-- 信令資料

 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相關介面的。

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；
 自適應音訊和視訊位元速率演算法適應可用的網路頻寬；