正文開始
上一篇文章中,咱們已經學習完了 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 後建立連線的流程。
- 用戶 A 向 Server 發送進行會話,內容包含 A 的 SDP。
- Server 將會話 SDP A 請求發送給用戶 B。
- 用戶 B 向 Server 進行應答,並回應 B 的 SDP。
- Server 向用戶 A 發送 用戶 B 的 SDP。
- 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 要進行會話
- A 與 B 分別至 Http 取得畫面,並且雙方都會使用 polling 來定時拉取 Signaling Server 看看有沒有人要和某方進行會話
- A 發送會話請求,並附加 A 的 SDP。
- B Polling 到有會話請求。
- B 回覆會話請求,並附加 B 的 SDP。
- A Polling 到 B 的會話回覆。
- 雙方開始建立連線。
這裡主要使用的技術就是基本的 HTTP,並且使用 Polling 機制來定期的探訪 Signaling Server。
WebSocket
WebSocket 它允許瀏覽器與 Server 建立一個雙向的溝通連線,就也就可以不需要使用 Polling 來定期的探訪 Signaling Server,而是只是它有收到會話請求,就會自動的推到某個用戶的瀏覽器。
- 用戶 A 向 Server 發送進行會話,內容包含 A 的 SDP。
- Server 將會話 SDP A 請求使用 WebSocket 發送給用戶 B。
- 用戶 B 向 Server 進行應答,並回應 B 的 SDP。
- Server 使用 WebSocket 向用戶 A 發送 用戶 B 的 SDP。
- A、B 雙方使用 SDP 開始建立連線。
備註: 前一篇文章『30-26之 WebRTC 的 P2P 即時通信與小範例』範例使用的 peer 套件,就是使用 WebSocket 方案來進行。
結論
本篇文章中咱們學習 WebRTC 要進行 P2P 連線的其中一個要角 Signaling Server,接下來我們就要開來說明 WebRTC 如何進行連線,不過在開始學習他如何進行連線前,咱們要先學習一下,一些傳統上 P2P 連線的相關問題。