黑色好看版 - 傳送門

正文開始

上一篇文章中，咱們已經學習完了 WebRTC 的一些基本知識，接下來咱們要針對 Signaling Server 這東東來做做一些比較深的的探討。

• Signaling Server 要做的事情。
• WebRTC 與 SDP。
• Signaling Server的實作選擇。

Signaling Server 要做的事情

在上一篇文章，我們大概知道了 Signaling Server 要做的事情，它要做的就是：

在建立 WebRTC 時，讓不認識的雙方可以相互的認識 (也就是知道對方的位置)

順到說一下 WebRTC 並沒有定議 Signaling Server 的標準。

那 Signaling 是如何讓雙方知道對方的位置呢 ?

Signaling 是如何讓雙方認識呢 ?

它就像是一個交友仲介商，每當某位用戶要進行聯誼時，用戶會提交一份履歷，這裡面就寫這他家在那，然後有配對到時，就會將這份履歷交給配對者，然後配對者如果覺得可以認識看看，他也會提供一份履歷給 Signaling Server，這樣雙向就可以進行面談了，其中已 Signaling 角度而言，履歷就是指 SDP。

什麼是 SDP ?

下章節在說。

為啥 WebRTC 不建立 Signaling Server 的標準呢 ?

因為事實上要讓兩個瀏覽器能進行溝通，可以不需要 Signaling Server，如果你知道對方在那的情況下，在筆者的『30-10之通訊協議的基本常識』這篇文章中有提到，假設你知道了對方的 port 就代表你可以找到對方電腦內某個應用程式的位置，而你知道了 ip 那就代表你知道對方在那，所以這時你事實上就可以與對方溝通。

WebRTC 與 SDP

SDP (Session Description Protocol) 中文叫會話描述協議，在一段會話建立起來前，咱們需要一些建立這會話雙方的資訊，假設 A 與 B 要建立會話，所以這時 A 會發送一個 SDP 給 Signaling，內容包含了 A 的地址、媒體類型、傳輸協議、媒體格式等或是一些它所在的時區資訊，然後 Signaling 會將 A 發送的 SDP 給 B，這樣雙方就知道如何建立連線了。

下圖為 WebRTC 加上 SDP 後建立連線的流程。

1. 用戶 A 向 Server 發送進行會話，內容包含 A 的 SDP。
2. Server 將會話 SDP A 請求發送給用戶 B。
3. 用戶 B 向 Server 進行應答，並回應 B 的 SDP。
4. Server 向用戶 A 發送 用戶 B 的 SDP。
5. A、B 雙方使用 SDP 開始建立連線。

SDP 格式描述

一般 SDP 分為三個部份組成。下圖為官網範例，然後咱們簡單的理解一下每個參數。

• v = 協議版本
• o = 發起者的 SDP 編號與位置
• s = 會話名稱 (可空白)
• c = 連線資訊 (如果包含在媒體中可以不需要)
• t = 會話活動時間
• m = 媒體名稱與傳輸位置。
• a = 媒體的屬性 (就通常是描述 m 所指的媒體屬性)

其中有個參數要說明一下，那就是m，它在上面的說明為娛體的名稱為傳輸位置，但那是以官網的英文翻譯過來的，實際上它包含四個參數，分別：

• 媒體類型：範例為 audio
• 發送媒體流的 port：範例為 49170
• 傳輸協議：RTP
• 媒體 payload 類型：下面範例你看到三個數字 0、8、97，它們分別代表對應的類型 PCMU、PCMA、iLBC，這也對應了下面a的那三個編碼。更多類弄請參考

[Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 8 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31 32
      a=rtpmap:31 H261/90000
      a=rtpmap:32 MPV/90000

[Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49174 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 49170 RTP/AVP 32
      a=rtpmap:32 MPV/90000

SDP 的詳細說明請參考『RFC4317-Session Description Protocol (SDP)』

Signaling Server 的實作選擇

由於 WebRTC 並沒有定議我們要如何實作 Signaling Server 因此這裡將說明比較常見的兩種做法。

HTTP

這個方案的基本流程如下：

假設用戶 A 與 B 要進行會話

1. A 與 B 分別至 Http 取得畫面，並且雙方都會使用 polling 來定時拉取 Signaling Server 看看有沒有人要和某方進行會話
2. A 發送會話請求，並附加 A 的 SDP。
3. B Polling 到有會話請求。
4. B 回覆會話請求，並附加 B 的 SDP。
5. A Polling 到 B 的會話回覆。
6. 雙方開始建立連線。

這裡主要使用的技術就是基本的 HTTP，並且使用 Polling 機制來定期的探訪 Signaling Server。

WebSocket

WebSocket 它允許瀏覽器與 Server 建立一個雙向的溝通連線，就也就可以不需要使用 Polling 來定期的探訪 Signaling Server，而是只是它有收到會話請求，就會自動的推到某個用戶的瀏覽器。

1. 用戶 A 向 Server 發送進行會話，內容包含 A 的 SDP。
2. Server 將會話 SDP A 請求使用 WebSocket 發送給用戶 B。
3. 用戶 B 向 Server 進行應答，並回應 B 的 SDP。
4. Server 使用 WebSocket 向用戶 A 發送 用戶 B 的 SDP。
5. A、B 雙方使用 SDP 開始建立連線。

備註：
前一篇文章『30-26之 WebRTC 的 P2P 即時通信與小範例』範例使用的 peer 套件，就是使用 WebSocket 方案來進行。

結論

本篇文章中咱們學習 WebRTC 要進行 P2P 連線的其中一個要角 Signaling Server，接下來我們就要開來說明 WebRTC 如何進行連線，不過在開始學習他如何進行連線前，咱們要先學習一下，一些傳統上 P2P 連線的相關問題。

參考資料

• 實做Signaling Server與WebRTC 連接前之交互流程
• WebRTC 中的 SDP 协议