前兩篇blog介紹了P2P的原理和libjingle庫的基本情況，如果直接看代碼，很多細節可能不會注意到，這種時候最有效的方法當然是看它的開發文檔，因為庫是由Google開發和維護，所以這方面我們不用擔心，文檔首頁見
這里。但是如果要深入了解庫代碼為什么這么寫，為什么這么約定時，還需要了解相應的協議。
便于大家了解，特整理如下。(轉載請注明作者和出處 by peakflys)
一、相關協議簡介
·XMPP協議（核心協議）：
全稱：The Extensible Messaging and Presence Protocol，即可擴展通訊和表示協議。說白了，就是規定基于XML流傳輸指定節點數據的協議。這么做的好處就是統一(peakflys注：大家都按照這個定義，做的東西就可以相互通訊、交流，這個應該很有發展前景！)。它是一個開放并且可擴展的協議，包括Jingle協議 都是XMPP協議的擴展。(peakflys注：使用Wireshark抓包時，早期的版本可能找不到這個協議，這時候可以選擇Jabber，它是XMPP協議的前身)。現在很多的IM都是基于XMPP協議開發的，包括gtalk等。
·Jingle協議（重要的協議）：
Jingle協議是XMPP協議上的擴展協議，它著手解決在XMPP協議框架下的點對點的連接問題，也即P2P連接。在Jingle框架下，即使用戶在防火墻或是NAT網絡保護之下，也能夠建立連接，從而提供文件傳送、視頻、音頻服務等。綱領性文件是XEP-0166
·TURN協議：
全稱：Traversal Using Relays around NAT，顧名思義，就是通過中繼服務器來傳輸數據的協議。
·STUN協議：
全稱：Simple Traversal of UDP over NATs，即NAT 的UDP簡單穿越，它允許位于NAT（或多重NAT）后的客戶端找出自己的公網地址，查出自己位于哪種類型的NAT之后以及NAT為某一個本地端口所綁定的Internet端端口。知道NAT類型并且有了公網IP和port，P2P就方便多了。
·ICE協議：
全稱：Interactive Connectivity Establishment，即 交互式連接建立，說白了，它就是利用STUN和TURN等協議找到最適合的連接。
二、Libjingle和各協議的關系
Jingle協議的發起方是Google，而libjingle庫也是Google公司實現，ICE協議又基本包含在Jingle協議里，所以只需要知道libjingle和Jingle協議的區別即可。
歷史：Libjingle大概和jingle XMPP 擴展在同一時間被建立。Libjingle的團隊建立了他們自己的協議去處理回話協商，后來和使用標準化的jingle（基于XMPP的標準）一起工作。盡管，jingle和libjingle是非常相似的，但是它們是不一樣的，而且不能共同使用。現在libjingle的源碼版本依然使用原始的網絡協議，跟以前的稍微有些不同，而且無法兼容jingle的規范。不過它還是足夠的接近jingle，所以學習jingle的說明書是值得的。類似的“接近但不是一樣”，libjingle的視頻內容描述（早期的jingle的視頻內容描述格式XEP-0167），ICE的傳輸描述（早期的jingle的ICE傳輸XEP-0176），以及流的UDP描述（早期的jingle流UDP的傳輸描述XEP-0177）
三、相關文檔：
RFC3921（下載：
RFC3921） XMPP協議的核心文檔
RFC3489(STUN)（下載：
RFC3489） STUN協議的草案
xep-0166(Jingle)（下載：
XEP-0166） Jingle協議的官方主體文檔
xep-0176(Jingle ICE-UDP)（下載：
XEP-0176）
定義Jingle和ICE結合的官方文檔（主要就是用XMPP作為ICE信道來重新描述ICE協議）
--by peakflys 15:30:19 Monday, February 04, 2013