WebRTC Signaling

WebRTC シグナリングは、デバイス間でメタデータを交換し、ピアツーピア接続を確立するために使用されます。このプロセスの中心となるのが セッション記述プロトコル（SDP, Session Description Protocol） です。これは、メディア通信セッションを記述し、オーディオおよびビデオコーデック、ネットワークトポロジー、その他のデバイス固有の詳細を含むパラメーターを交渉することを可能にします。SDP は、WebRTC デバイスが「通信」するための「言語」として機能します。

WHIP (WebRTC-HTTP Ingestion Protocol) および WHEP (WebRTC-HTTP Egress Protocol) が登場する以前、SDP データを転送する標準化された方法は存在しませんでした。CDNetworks では、SDP 転送に JSON ファイルを使用することでこのギャップを解消しています。本ガイドでは、このアプローチの詳細、これら JSON ファイルの構造、および WebRTC セッションのセットアップにおける使用方法を説明します。

1. URL 形式

CDNetworks における WebRTC の URL 形式は以下の通りです：

http://domain/appName/streamName.sdp?params=xxx

パラメーターの説明

• domain: ドメイン名を表します。例: stream.cdnetworks.com。
• appName: プッシュポイントを表します。例: live。
• streamName: ストリーム名を表します。例: channel_001。
• params: オプションのパラメーターを表します。例: userid=123。

注意：
この形式は RTMP および HTTP-FLV の URL 形式に似ていますが、主な違いは .sdp サフィックスです。
比較例：

• RTMP: rtmp://stream.cdnetworks.com/live/channel_001?userid=123
• HTTP-FLV: http://stream.cdnetworks.com/live/channel_001.flv?userid=123

2. ストリーミングのルール

ストリーミング URL 形式およびサーバー応答ルール

プッシュおよび再生ストリームの URL 形式は同一です。違いは WebRTC ネゴシエーションプロセスの重要な要素であるクライアント SDP の offer 属性に基づきます。この属性は、発信デバイスのメディア機能（対応コーデック、メディアタイプ（オーディオ、ビデオ）、ネットワーク詳細、およびデバイスが送信、受信、またはその両方を行うかどうか）を指定します。

クライアント Offer ルール：

• プッシュ: a=sendonly を含み、デバイスがメディアデータを送信するだけであることを示します。
• 再生: a=recvonly を含み、デバイスがメディアデータを受信するだけであることを示します。

注意: a=sendrecv（送信と受信を同時に行う）を使用するシナリオはサポートされていません。サポートされていない操作を回避するために、設定で a=sendonly または a=recvonly を指定してください。

offer を送信した後、相手デバイスまたはサーバーは answer SDP で応答し、セッションパラメーターを最終的に確定します。

サーバー応答ルール

サーバーの answer SDP はリクエストタイプに基づいて生成されます：

• プッシュリクエスト: サーバーは a=recvonly で応答します。
• 再生リクエスト: サーバーは a=sendonly で応答します。

3. シグナリングインタラクション仕様

リクエスト方法

• HTTP メソッド: POST
• リクエスト形式: JSON

リクエストパラメーター

応答パラメーター

4. SDP 定義

5. ステータスコード説明

6. リクエストと応答の例

リクエスト例

{
  "sessionId": "123456789",
  "version": "v1.0",
  "localSdp": {
    "type": "offer",
    "sdp": "<標準 SDP プロトコル内容>"
  }
}

応答例

{
  "code": 200,
  "message": "success",
  "remoteSdp": {
    "type": "answer",
    "sdp": "<標準 SDP プロトコル内容>"
  }
}