WHIPとWHEPの違いについて

WebRTCは、Googleが開発した通信方式であり、RTPやTURN、STUNなど様々なプロトコルが含まれています。

WebRTCは、名前の通り、リアルタイムコミュニケーションを目的に仕様が決められたため、クライアント同士はPeer to Peerで接続することを前提にしています。

ただ、現在では、低遅延配信としてWebRTCを使うケースがあり、その際に受信と送信が別々で考えられるケースがほとんどです。

https://speakerdeck.com/yaminoma/dong-hua-pei-xin-ji-shu-nituite

WebRTCにはSFUという中間サーバ側で、それぞれのコネクションをまとめて再送信したり、MCUといってストリームを合成して1本で送り返したりする技術もありますが、このP2Pに頼り切っている仕組みをなんとかしようとして現在仕様作成しているのがWHIPとWHEPです。

WHIPとWHEP

WHIPは、Ingestion（送信）側の仕様であり、WHEPは Egress（受信）側の仕様です。

WHIP (WebRTC-HTTP ingestion protocol)

WHIPの特徴的なのがシグナリングが仕様として定められており、HTTPベースのやり取りになっています。通常、WebRTCの場合はシグナリングについては仕様で決めておらず、一般的にはWebSocketを使ってSDPをやり取りするケースがほとんどです。WHIPでは、様々な環境に対応するために、シグナリングをHTTPベースにし、エラーコードの定義などもあります。

WHIPの設計思想として、RTMPのようにシンプルなURIを目的としているため、送る側はシンプルに送ることができます。

WHIPのクライアント（通常は配信ソフト）がサーバに対して、SDP OfferをPOSTすると、ResponseとしてAnswerが返ってきます。Answerをもとに、ICEのレスポンスやDTLSの接続、RTPの接続を行うことでWebRTCが確立されます。

また、WHIPのエンドポイント（配信URI）は、WebRTCのサーバとは別にあるので、ロードバランサーとして負荷分散させることも可能です。

WHEP (WebRTC-HTTP Egress Protocol)

WHEPのエンドポイントはWHIP同様に一意のURIで提供されるため、URIを知っていれば再生できます。このエンドポイントをMPEG-DASHのプレイリストに含めようという提案がIETF外のDASH-IFで議論されています。ちなみに筆者もDASH-IFのメンバーであり、この話はよくしています。

DASHのプレイリストはxmlで定義されており、独自のタグを拡張することが出来ます。そのため、WHEPのエンドポイントをプレイリストに含めることで、視聴するクライアントはWebRTCによる超低遅延か、DASHによる低遅延かを選ぶことが出来ます。

DASH-IFのリファレンスが公開されているので、詳しい話はこちらをご覧ください。

https://eyevinntechnology.medium.com/example-setup-of-a-combined-mpeg-dash-and-webrtc-distribution-77a7eaad7b2e

基本的なネゴシエーションはWHIPと同様ですが、視聴に特化した機能があります。

まず、Server Sent Events REST APIです。これは、WHEPで接続した際に、サーバから送られてくるAPIですが、配信のステータス（active/inactive）や、視聴者数(viewercount)や、配信画面の詳細な情報(layer)をクライアントに送ることが出来ます。これにより入室した際に、配信サーバ側から正確なデータが取得できるので、いわゆる視聴者数のズレなどが起きにくくなります。

また、layerを活用することで、Adaptive-Bitrateを実現することもできます。

layerには以下のようなJSONペイロードが送られてきます。

{
  "0": {
    "active": [
      {
        "id": "1", "simulcastIdx": 1, "bitrate": 538288, width: 640, height: 360
      },
      {
        "id": "0", "simulcastIdx": 0, "bitrate": 111600, width: 320, height: 180
      }
    ],
    "inactive": [
      {
        "id": "2", "simulcastIdx": 2
      },
    ],
    "layers": [
      { "encodingId": "1", "simulcastIdx": 1, "spatialLayerId": 0, "temporalLayerId": 1, "bitrate": 557112, width: 640, height: 360 },
      { "encodingId": "1", "simulcastIdx": 1, "spatialLayerId": 0, "temporalLayerId": 0, "bitrate": 343592, width: 640, height: 360 },
      { "encodingId": "0", "simulcastIdx": 0, "spatialLayerId": 0, "temporalLayerId": 1, "bitrate": 116352, width: 320, height: 180 },
      { "encodingId": "0", "simulcastIdx": 0, "spatialLayerId": 0, "temporalLayerId": 0, "bitrate": 67464 , width: 320, height: 180 }
    ]
  }
}

WebRTCにはサイマルキャストといって、1本のストリームに複数の画質を含めることができ、レイヤーではそのサイマルキャストの中身が表示されています。クライアントはこのメタを読むことで、Adaptive Bitrateが実現することが出来ます。

対応サービスについて

そんなWHEPとWHIPですが、Cloudflare Streamはいち早く対応を始めており、今後もWHEPとWHIPをサポートするサービスも増えていくと思います。