ROAP

ROAP 就是 RTCWeb Offer/Answer Protocol 實(shí)時(shí)網(wǎng)頁提議應(yīng)答協(xié)議
這是一個(gè)新協(xié)議, 目的是為了搭建媒體通道, 由思科,谷歌及Mozilla的幾位工程師提出, 還在草案階段, 并未正式發(fā)布.

這本應(yīng)該是 SIP(Session Initiation Protocol) 協(xié)議之所長, 為什么不是 SIP, 我想還是在于 SIP 太重了
WebRTC所提供的 API 本來就比較簡單, 沒必要為了搭媒體就引入 SIP 這樣復(fù)雜的一個(gè)協(xié)議.

先看下在 SIP 中如何搭建媒體通道

SIP-Flow

Web一般是基于HTTP的, 為什么不能簡單地通過 HTTP request/response 來協(xié)商搭建媒體通道呢
主要是因?yàn)榇罱襟w通道需要協(xié)商很多參數(shù)

SDP

這種協(xié)商需要一個(gè)討價(jià)還價(jià)和確認(rèn)的過程, 所以需要三步, 而不能僅僅一來一回兩條消息, 例如

1. 張三問李四水果一斤多少錢, 2) 李四說蘋果三元, 桔子四元, 香蕉五元, 3) 張三說那就來斤蘋果吧

消息 Messages

• 提議 Offer

    {
      "messageType":"OFFER",
      "offererSessionId":"13456789ABCDEF",
      "seq": 1,
      "sdp":"
    v=0\n
    o=- 2890844526 2890842807 IN IP4 192.0.2.1\n
    s= \n
    c=IN IP4 192.0.2.1\n
    t=2873397496 2873404696\n
    m=audio 49170 RTP/AVP 0"
    }
  

• 應(yīng)答 Answer

    {
     "messageType":"ANSWER",
     "offererSessionId":"13456789ABCDEF",
     "answererSessionId":"abc1234356",
     "seq": 1,
     "sdp":"
   v=0\n
   o=- 2890844526 2890842807 IN IP4 192.0.2.3\n
   s= \n
   c=IN IP4 192.0.2.3\n
   t=2873397496 2873404696\n
   m=audio 49175 RTP/AVP 0"
   }
  

• 確認(rèn) Confirm

    {
     "messageType":"OK",
     "offererSessionId":"13456789ABCDEF",
     "answererSessionId":"abc1234356",
     "seq": 1
   }
  

通過以上的消息交互流程, 最終協(xié)商出 在 192.0.2.1:49170 和 192.0.2.3:49175 之間傳輸 audio , codec 是 PCMU (g.711 u-law)

ROAP 消息一般都通過可靠的通道傳輸, 比如通過 XMLHttpRequst 或者 WebSocket 承載的 HTTP 消息

通用字段

會(huì)話標(biāo)識 Session IDs

Each call is identified by a pair of session identifiers:
每個(gè)呼叫由一對 ID 來標(biāo)識, 要求它們是全局唯一的, 所有的消息都要有 offererSessionId, 響應(yīng)式消息都還要有 answererSessionId

• offererSessionId
• answererSessionId

序列號 Seq

消息的序列編號, 是一個(gè)32位的無符號整數(shù), 每個(gè)新的 Offer 都會(huì)加1

會(huì)話令牌 Session Tokens

session ID用來唯一標(biāo)識一個(gè)session, session token則用標(biāo)識一個(gè)會(huì)話的生命周期

如收到帶有 setSessionToken 的字段則以 sessionToken 回應(yīng), 沒有則忽略

Response Tokens

response token則用標(biāo)識一個(gè)請求/應(yīng)答的生命周期

如收到帶有 setResponseToken 的字段則以 responseToken 回應(yīng), 沒有則忽略

媒體通道搭建過程 Media Setup

ROAP media setup

上圖顯示了用于媒體協(xié)商的簡單消息流：

• 提議者發(fā)送 OFFER 來發(fā)起呼叫; 此時(shí)，ICE協(xié)商開始;

• 一旦瀏覽器授權(quán)向遠(yuǎn)端發(fā)送媒體删豺，應(yīng)答者就發(fā)送包含媒體參數(shù)的 ANSWER;

• 最后回溺，一旦 ICE 完成并收到對于 ANSWER 的 OK 消息，雙方就都知道媒體通道搭建成功了等脂。

Offer 消息

第一個(gè)OFFER消息包含一個(gè)給定的 offererSessionId, 它用來指示期望開始一個(gè)媒體會(huì)話

Offerer 行為

為了開始一個(gè)新的媒體會(huì)話咳燕，提議者使用新的 offerefereSessionId 來構(gòu)造一個(gè)新的OFFER消息也祠。 這時(shí) answererSessionId 字段必須為空插龄。 像所有SDP Offer 的那樣愿棋，消息體必須包含一個(gè)帶有提議者所提議的“sdp”字段。 它還必須包含 tieBreaker字段均牢，包含一個(gè)用于解決沖突的32位隨機(jī)整數(shù) ( ROAP 中稱沖突的 OFFERS 為 glare)

Answerer 行為

一個(gè)回應(yīng)者可以在以下三種情況下收到一個(gè)提議 OFFER：

• 一個(gè)新的會(huì)話（通過查看是否有新的 offerefereSessionId 值來檢測;
• 一個(gè)新的 OFFER的重傳（已知的 offererSessionId糠雨，空的answererSessionId;
• 一個(gè)更改媒體參數(shù)的請求（已知 offererSessionId，已知的 answererSessionId徘跪，新的 seq值）见秤。

除了上述三種情況, 任何其他條件所表示的外來數(shù)據(jù)包應(yīng)被拒絕為錯(cuò)誤：NOMATCH

如果不存在具有給定 “offererSessionId” 值的媒體會(huì)話砂竖，那么這就是新的媒體會(huì)話。 回應(yīng)者有以下三個(gè)主要的選項(xiàng)：

• 拒絕請求鹃答，或者不回響應(yīng), 或者回復(fù)錯(cuò)誤：REFUSED消息;
• 使用最終的 ANSWER 消息來回復(fù)OFFER消息;
• 先回復(fù)非最終的 ANSWER消息，然后再回復(fù)最終的 ANSWER 響應(yīng)突硝。

在后而兩者中的任何一種情況下测摔，回應(yīng)者執(zhí)行以下步驟：

1. 生成一個(gè) “answererSessionId”值;
2. 創(chuàng)建一些本地呼叫狀態(tài) call state（即 PeerConnection對象）并將其綁定到 “offererSessionId/answererSessionId” 這一對值上面。 此會(huì)話中后續(xù)的所有消息必須傳遞給該P(yáng)eerConnection對象;
3. 與提議者開始 ICE 握手; 最后解恰，
   4.在 “sdp” 字段中回復(fù)包含 SDP 響應(yīng)的消息, 包含回應(yīng)者（可能帶有 moreComing = true）媒體信息和ICE參數(shù)锋八。

如果收到一個(gè)在這之前已經(jīng)收到并回復(fù)的 OFFER, 并且媒體會(huì)話仍然存在，那么回應(yīng)者必須
回復(fù)與以前相同的消息护盈。 如果會(huì)話已在此期間終止挟纱，則應(yīng)回復(fù) Error：NOMATCH消息。

Answer 消息

OFFER 消息的接收者使用ANSWER消息來指示該提議已被接受腐宋。 ANSWER消息必須包含該媒體會(huì)話的 answererSessionId , ICE候選者的 sdp參數(shù), 以及會(huì)話的最終媒體參數(shù)（當(dāng)然這些參數(shù)可以通過新的OFFER / ANSWER交換進(jìn)行調(diào)整）

此外紊服，ANSWER可以包含moreComing標(biāo)志，如下所述胸竞。

• moreComing Flag

這個(gè)flag表示這個(gè)應(yīng)答消息是否為最終響應(yīng), moreComing=true代表此應(yīng)答消息不是最終響應(yīng), 默認(rèn)為false

• OK
  無錯(cuò)響應(yīng)

• ERROR
  有錯(cuò)響應(yīng)

媒體通道沖突協(xié)商流程

MediaConflictNegotiation

媒體通道關(guān)閉流程

MediaTermination

提示 Hints

當(dāng)在瀏覽器中創(chuàng)建對端連接時(shí), 應(yīng)用程序需要能提供可選的媒體選項(xiàng)提示, 以供協(xié)商

1. 是否會(huì)議包含音頻,視頻,或者二者都有
2. 音頻是語音還是音樂
3. 期望的視頻精度和幀率 (或許就從 MediaTrack 對象中獲取);
4. 是否視頻有期望的時(shí)間或空間精度;
5. 等等

參考鏈接

• ROAP protocol
• An Offer/Answer Model with the Session Description Protocol (SDP)
• RTP Profile for Audio and Video Conferences with Minimal Control
• SDP: Session Description Protocol
• WebRTC introduction
• WebRTC basic tutorial
• WebRTC infrastructure tutorial