WebRTC 與信令

WebRTC 允許在兩個設備之間進行實時的 P2P 媒體通訊。由于存在 NAT ，WebRTC 不能直接與對端建立連接，設備之間需要通過信令服務進行發現和協商以進行實時音視頻交換。這涉及到兩個設備連接到第三個共同商定的服務器，一般被稱為信令服務器。信令服務器的作用是作為一個中間人幫助雙方在盡可能少的暴露隱私的情況下建立連接。通過這個第三方服務器，這兩臺設備可以相互定位，并交換協商消息。

值得注意的是信令服務器不需要理解和解釋信令數據內容。雖然信令消息使用 SDP 協議，但這并不重要：信令服務器實際上是一個黑盒，消息內容會直接被傳送。當 WebRTC 的 ICE 子系統指示你將信令數據發送給對端時，信令服務器直接傳遞消息，而對端接收此信息并將其傳遞給自己的 ICE 子系統。信令服務器所要做的就是來回傳遞信息。內容對信令服務器一點都不重要。

信令

信令是在兩個設備之間發送控制信息以確定通信協議、信道、媒體編解碼器和格式以及數據傳輸方法以及任何所需的路由信息的過程。 關于 WebRTC 的信令流程最重要的一點是：信令在規范中并沒有定義。所以開發者需要自己決定如何實現這個過程。開發者可以為應用程序引擎選擇任意的信息協議（如SIP或XMPP），任意雙向通信信道（如 WebSocket 或 XMLHttpRequest )與持久連接服務器的 API 一起工作。

為了交換信令信息，您可以選擇通過WebSocket連接來回發送JSON對象，或者您可以在適當的通道（Channel）上使用 XMPP 或 SIP，或者您可以通過 HTTPS 使用 XMLHttpRequest 進行輪詢或者其他任何你可以想出來的技術組合。你甚至可以使用電子郵件作為信號通道。

信令期間交換的信息

信令期間需要交換的信息有三種基本類型：

• 控制消息：用于設置、打開、關閉通信通道并處理錯誤。
• 為了建立連接所需的信息：設備間能夠彼此交談所需的IP尋址和端口信息。
• 媒體能力協商：交互雙方可以理解哪些編解碼器和媒體數據格式？ 這些都需要在WebRTC會議開始之前達成一致。

只有在信令成功完成之后，打開WebRTC對等連接的過程才真正開始。

信令過程

為了開啟一個 WebRTC 會話，以下事件需要依次發生：

1. 每個 Peer 創建一個 RTCPeerConnection 對象，用來表示其 WebRTC 會話端。
2. 每個 Peer 建立一個 icecandidate 事件的響應程序，用來在監測到該事件時將這些 candidates 通過信令通道發送給另一個 Peer。
3. 每個 Peer 建立一個 track 事件的響應程序，這個事件會在遠程 Peer 添加一個 track 到其 stream 上時被觸發。這個響應程序應將 tracks 和其消受者聯系起來，例如 <video> 元素。
4. 呼叫者創建并與接收者共享一個唯一的標識符或某種令牌，使得它們之間的呼叫可以由信令服務器上的代碼來識別。此標識符的確切內容和形式取決于您。
5. 每個 Peer 連接到一個約定的信令服務器，如 WebSocket 服務器，他們都知道如何與之交換消息。
6. 每個 Peer 告知信令服務器他們想加入同一 WebRTC 會話（由步驟4中建立的令牌標識）。
7. 描述，候選地址等