Connections（鏈接）
一個p2p的鏈接實際上由兩個通道組成。
● session negotiation channel（也稱作signaling channel），會話協商通道。是為數據鏈接服務的溝通通道。這個通道被用來回應取得一個鏈接的請求，交換候選，和協商會話的細節（比如：套接字地址，需要的編碼方案，交換的文件，鏈接改變請求，終止請求）。這個通道是兩個計算機之間建立的第一個鏈接，也只有這個鏈接成功之后，兩個計算機之間的數據鏈接才能被建立。libjingle通過發送一個指定的前導協議節發出一次響鈴并收到一個回應，數據鏈接則被建立（see Jingle and libjingle）。這個通道發送協議節是通過XMPP 服務器這一中間機構進行的，例子中的代碼是把Google Talk服務器當作中間機構用的。
● data channel （婁據通道，數據鏈接）這個通道傳送的是p2p兩端真正交換的數據（語音，視頻，文件等），數據通道里的數據被TCP或UDP包封裝，到底是TCP還是UDP這要視協商的傳送方式，這些包并沒有經過XMPP服務器。
會話協商通道首先被建立，它作為計算機間協商建立數據通道細節的通道。數據通道被成功建立之后，在這個通道上將發生許多數據活動，除非碰到改變編碼請求，新文件請求，重傳請求，或終止請求。
下面的圖演示了這兩種數據路徑。盡管只有一個路徑處于活動態，圖中還列出了兩個路徑的交替使用態。因為路徑可以是直接鏈接（92%的鏈接嘗試都可以轉換成直聯）或服務器中轉（8%的鏈接嘗試需要中間服務器的中轉）。第三種數據路徑沒有列出，它是沒有防火墻的網絡中從一臺計算機直接鏈接另一臺計算機。
注意：
1、libjingle不時地發送出心跳包（STUN），來維持一個鏈接可寫入，保持防火墻和NAT地址綁定處于活動態，并且還可用來檢查潛在的鏈接。
2、linjingle向鏈接端口分配用戶名和密碼。此舉用來確定當前鏈接的數據通道就是在會話協商通道上協商好的數據通道。因為用戶名和密碼是被XMPP發出的，也許沒有經過TLS的加密，心跳包中的用戶名和密碼只是身份的標識，并沒有加密驗證。
運行 file share 例子程序，可以看到發出的真實協議節。