ROAP

ROAP 就是 RTCWeb Offer/Answer Protocol 实时网页提议应答协议
这是一个新协议, 目的是为了搭建媒体通道, 由思科,谷歌及Mozilla的几位工程师提出, 还在草案阶段, 并未正式发布.

这本应该是 SIP(Session Initiation Protocol) 协议之所长, 为什么不是 SIP, 我想还是在于 SIP 太重了
WebRTC所提供的 API 本来就比较简单, 没必要为了搭媒体就引入 SIP 这样复杂的一个协议.

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

SIP-Flow

Web一般是基于HTTP的, 为什么不能简单地通过 HTTP request/response 来协商搭建媒体通道呢
主要是因为搭建媒体通道需要协商很多参数

SDP

这种协商需要一个讨价还价和确认的过程, 所以需要三步, 而不能仅仅一来一回两条消息, 例如

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"
    }
  

• 应答 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"
   }
  

• 确认 Confirm

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

通过以上的消息交互流程, 最终协商出 在 192.0.2.1:49170 和 192.0.2.3:49175 之间传输 audio , codec 是 PCMU (g.711 u-law)

ROAP 消息一般都通过可靠的通道传输, 比如通过 XMLHttpRequst 或者 WebSocket 承载的 HTTP 消息

通用字段

会话标识 Session IDs

Each call is identified by a pair of session identifiers:
每个呼叫由一对 ID 来标识, 要求它们是全局唯一的, 所有的消息都要有 offererSessionId, 响应式消息都还要有 answererSessionId

• offererSessionId
• answererSessionId

序列号 Seq

消息的序列编号, 是一个32位的无符号整数, 每个新的 Offer 都会加1

会话令牌 Session Tokens

session ID用来唯一标识一个session, session token则用标识一个会话的生命周期

如收到带有 setSessionToken 的字段则以 sessionToken 回应, 没有则忽略

Response Tokens

response token则用标识一个请求/应答的生命周期

如收到带有 setResponseToken 的字段则以 responseToken 回应, 没有则忽略

媒体通道搭建过程 Media Setup

ROAP media setup

The above figure shows a simple message flow for negotiating media:

The offerer sends an OFFER to initiate the call;
At this point, ICE negotiation starts;

Once the browser authorizes sending media to the far side, the answerer sends an ANSWER containing the media parameters;

and finally,Once ICE is completed and an OK to the ANSWER is received, both sides know that media can flow.

Offer 消息

The first OFFER message with a given offererSessionId is used to indicate the desire to start a media session

Offerer 行为

In order to start a new media session, a offerer constructs a new OFFER message with a fresh offererSessionId. The answererSessionId
field MUST be empty. Like all SDP offers, the message MUST contain an "sdp" field with the offerer's offer. It MUST also contain the
tieBreaker field, containing a 32 bit random integer used for glare resolution

Answerer 行为

A answerer can receive an OFFER in three cases:

• A new session (this is detected by seeing a new offererSessionId value);
• A retransmit of a new OFFER (known offererSessionId, empty answererSessionId); or
• A request to change media parameters (known offererSessionId, known answererSessionId, new seq value).

The first two situations are described in this section. The third case is described in . Any other condition represents an alien packet and SHOULD be rejected with Error:NOMATCH

If no media session exists with the given "offererSessionId" value, then this is a new media session. The answerer has three primary
options:

• Reject the request, either silently with no response or with an Error:REFUSED message;
• Reply to the OFFER message with a final ANSWER message; or
• Send back a non final ANSWER message and then later respond with an final ANSWER.

In either of the latter two cases, the answerer performs the following steps:

1. Generate a "answererSessionId" value;
2. Create some local call state (i.e., a PeerConnection object) and bind it to the "offererSessionId"/"answererSessionId" pair. all future messages on this session MUST then be delivered to that PeerConnection object;
3. Start ICE handshaking with the offerer; and finally,
4. Respond with a message containing an SDP answer in the "sdp" field. This will contain the answerer's (potentially with
   moreComing=true) media information and the ICE parameters.

If an OFFER is received that has already been received and responded to and the media session still exists, then the answerer MUST
respond with the same message as before. If the session has been terminated in the meantime, then an Error:NOMATCH message
SHOULD be sent.

Answer 消息

The ANSWER message is used by the receiver of an OFFER message to indicate that the offer has been accepted. The ANSWER message MUST contain the answererSessionId for this media session and an sdp parameter containing ICE candidates and the final media parameters for the session (although of course these can be adjusted by a new OFFER/ANSWER exchange. See ).

In addition, ANSWERs MAY contain the moreComing flag, as described below.

• moreComing Flag

这个flag表示这个应答消息是否为最终响应, moreComing=true代表此应答消息不是最终响应, 默认为false

• OK
  无错响应

• ERROR
  有错响应

媒体通道冲突协商流程

MediaConflictNegotiation

媒体通道关闭流程

MediaTermination

提示 Hints

当在浏览器中创建对端连接时, 应用程序需要能提供可选的媒体选项提示, 以供协商

1. 是否会议包含音频,视频,或者二者都有
2. 音频是语音还是音乐
3. 期望的视频精度和帧率 (或许就从 MediaTrack 对象中获取);
4. 是否视频有期望的时间或空间精度;
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