iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 27
2
Software Development

30天之即時網路影音開發攻略(小白本)系列 第 27

30-27之 WebRTC 的 Signaling Server

黑色好看版 - 傳送門


正文開始

上一篇文章中,咱們已經學習完了 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 開始建立連線。

https://ithelp.ithome.com.tw/upload/images/20181111/20089358Va51RZj26R.png

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 連線的相關問題。

參考資料


上一篇
30-26之 WebRTC 的 P2P 即時通信與小範例
下一篇
30-28之 WebRTC 連線前傳 - 為什麼 P2P 連線很麻煩 ? ( NAT )
系列文
30天之即時網路影音開發攻略(小白本)30

尚未有邦友留言

立即登入留言