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