sgcWebRTC が TsgcRTCPeerConnection に追加するすべてを、機能ごとに整理しています。シグナリングと接続性は sgcWebSockets Enterprise の基本コンポーネントに含まれています。このパックはその上にメディアエンジンを解放します。音声、映像、画面キャプチャ、データチャネル、暗号化、帯域幅推定です。すべての機能は Delphi と C++ Builder で同じように動作し、すべてのライセンスに完全なソースコードが付属します。
基本的な接続性はすでに sgcWebSockets に含まれています。sgcWebRTC は、同じコンポーネント上に SDP、データチャネル、メディアの領域を解放します。
| 機能 | 提供元 | 備考 |
|---|---|---|
STUN クライアント（TsgcSTUNClient） | sgcWebSockets Standard | サーバーリフレクシブ候補の発見で、Enterprise 未満でも利用できます。 |
TURN クライアント & サーバー、ICE クライアント（TsgcTURNClient、TsgcICEClient） | sgcWebSockets Enterprise | リレー候補と、完全な ICE 候補の収集・ノミネートです。 |
基本の TsgcRTCPeerConnection、従来型の WebSocket リレーシグナリング | sgcWebSockets Enterprise | GatherCandidates、WriteData、そして OnRTCWebSocket… / OnRTCCandidatePairNominated / OnRTCConnect イベントが、内蔵の RTCPeerConnection プロトコルサーバーを通じて ICE 接続性と DTLS トランスポートを駆動します。SDP、データチャネル、メディアはありません。 |
| 手動の SDP オファー/アンサーシグナリング | sgcWebRTC | CreateOffer、CreateAnswer、SetLocalDescription、SetRemoteDescription、AddIceCandidate、RestartIce。ブラウザーが期待する JSEP（RFC 8829）の状態機械です。 |
| 再ネゴシエーション & glare の解決 | sgcWebRTC | AddTrack / RemoveTrack 後の再オファー、OnNegotiationNeeded、ロールバック、そして Polite による W3C の perfect-negotiation ルールです。 |
| Trickle ICE | sgcWebRTC | TrickleICE と RTCOptions.TrickleICEAuto が、収集完了のタイムアウトを待たずに候補を見つかり次第ストリーミングします。 |
| コネクションとシグナリングの状態 | sgcWebRTC | ConnectionState（W3C RTCPeerConnectionState のサブセット）と SignalingState（RTCSignalingState のサブセット）に加え、OnConnectionStateChange と OnError です。 |
| SCTP データチャネル、RTP 音声/映像、SRTP 暗号化 | sgcWebRTC | 下記の各節を参照してください。3 つとも、Enterprise の基本機能に加えてこのパックが必要です。 |
1 回の AddTrack 呼び出しで音声トラックをピア接続に追加します。PCM を入力すると RTP が出力され、リモートトラックについても同じ経路が逆方向に動作します。
| 機能 | メンバー | 備考 |
|---|---|---|
| 音声トラックの追加 | AddTrack(rtctkAudio, aCodec) | TsgcRTCTrack を返します。RemoveTrack で送信を停止します。 |
| Opus コーデック | cctAudioOpus | 48 kHz / ステレオ。動的にロードされる libopus バインディング経由です。 |
| G.711 コーデック | cctAudioPCMU / cctAudioPCMA | 8 kHz / モノラルの μ-law と A-law で、外部ライブラリなしで常に利用できます。 |
| キャプチャした音声の送信 | TsgcRTCTrack.SendPCM(aPCM, aSamplesPerChannel) | エンコーダーのサンプルレートとチャンネル数に合わせた 16 ビット符号付きインターリーブ PCM です。 |
| デコードされた音声の受信 | OnAudio(aPCM, aSampleRate, aChannels, aSamplesPerChannel) | RTP が到着してデコードされるたびに、リモートトラック上で発生します。 |
| エンコーダー / デコーダーへのアクセス | AudioEncoder / AudioDecoder | その裏にある TsgcAudioEncoderBase / TsgcAudioDecoderBase オブジェクトで、トラックごとに差し替えられます。 |
| トラックのライフサイクル | Enabled、Ended、OnEnded | Enabled := False は再ネゴシエーションなしでミュートします。Ended は、リモート側でトラックが破棄されたか再オファーされたことを反映します。 |
| マイクのキャプチャ | TsgcMediaCaptureSource の派生クラス | プラットフォームごとのネイティブキャプチャ（Windows の waveIn に加え、Linux、Apple、Android の各バックエンド）が SendPCM に直接供給します。 |
映像も音声と同じ形をしています。フレームを入力すると RTP が出力されます。コーデックはトラックごとに選択でき、H.264 の場合はその下でプラットフォーム自身のハードウェアエンコーダーが動きます。
| 機能 | メンバー | 備考 |
|---|---|---|
| 映像トラックの追加 | AddTrack(rtctkVideo, aCodec) | 音声と同じ呼び出しで、映像用の TsgcCodecType を指定します。 |
| VP8 コーデック | cctVideoVP8 | 動的にロードされる libvpx バインディングで、Windows と Linux で利用できます。 |
| H.264 コーデック | cctVideoH264 | プラットフォームごとのネイティブハードウェアエンコーダーです: Media Foundation（Windows）、VideoToolbox（iOS/macOS）、MediaCodec（Android）。Annex-B ストリーム、RFC 6184 のペイロード化で、SPS/PPS はすべてのキーフレームにインバンドで運ばれます。 |
| Motion JPEG コーデック | cctVideoJPEG | GDI+ ベースで、Windows と Delphi XE 以降が対象です。 |
| 生フレームの送信 | TsgcRTCTrack.SendVideoFrame(aFrame, aForceKeyFrame) | TsgcVideoFrame（I420/NV12/RGB/BGR 系）をエンコードして送信します。 |
| エンコード済みフレームの送信 | SendEncodedFrame(aData, aIsKeyFrame) | 外部でエンコードされたフレームのために、トラック自身のエンコーダーをバイパスします。 |
| デコード済み / 生フレームの受信 | OnVideoFrame / OnEncodedFrame | デコードされた TsgcVideoFrame、またはキーフレームフラグ付きの生のエンコード済みビットストリームです。 |
| キーフレームの要求 | RequestKeyFrame | リモートの送信側に RTCP PLI を送ります。 |
| エンコーダー / デコーダーへのアクセス | VideoEncoder / VideoDecoder | その裏にある TsgcVideoEncoderBase / TsgcVideoDecoderBase オブジェクトです。 |
| カメラのキャプチャ | TsgcMediaCaptureSource の派生クラス | プラットフォームごとのキャプチャバックエンド（Windows、Linux、Apple、Android）が SendVideoFrame に直接供給します。 |
| 描画 | TsgcMediaRenderer の派生クラス | デコードされたリモート映像向けの、プラットフォームごとのレンダラーバックエンドです（Windows、Linux、Apple、Android）。 |
SCTP-over-DTLS 上で、順序保証あり/なし、完全な信頼性、または再送回数か有効期間で制限された配送に対応します。
| 機能 | メンバー | 備考 |
|---|---|---|
| チャネルを開く | CreateDataChannel(aLabel, aOrdered, aMaxRetransmits, aMaxPacketLifeTime, aProtocol) | TsgcRTCDataChannel を返し、RTCOptions.DTLS を強制的に有効にします。 |
| リモート側が開いたチャネル | OnDataChannel(aChannel) | ピアがこのコネクション上でチャネルを開くと発生します。 |
| テキスト / バイナリの送信 | Send(aText) / SendBytes(aBytes) | チャネルがまだ開いていない場合は False を返します。 |
| 受信 | OnMessage(aText) / OnMessageBinary(aBytes) | SCTP を駆動するスレッド上で発生します。 |
| ライフサイクルイベント | OnOpen、OnClose、OnError(aError) | W3C の RTCDataChannel のライフサイクルに一致します。 |
| チャネルの状態 | State、HasId、Id | SCTP のストリーム id は、DTLS の役割が確定して初めて確定します（RFC 8832 のパリティ）。 |
| フロー制御 | BufferedAmount、MaxMessageSize | MaxMessageSize はピア自身の a=max-message-size を追跡し、サイズ超過の送信をローカルで拒否します。 |
| 信頼性の確認 | Reliability、ReliabilityParam、Ordered、MaxRetransmits、MaxPacketLifeTime | チャネルがネゴシエートした内容をそのまま読み取れます。 |
| クローズ | Close | RE-CONFIG ベースのクローズです。State は closing を経て closed になり、OnClose が発生します。 |
| ピア接続レベル | DataChannelCount、DataChannels[i] | コネクション上で開いているすべてのチャネルを列挙します。 |
コネクション上のすべての RTP、RTCP、SCTP パケットは、DTLS ハンドシェイク以降、常に暗号化されています。平文モードはありません。
| 機能 | 詳細 |
|---|---|
| 鍵交換 | 指名された ICE 候補ペア上での DTLS ハンドシェイク（RFC 5764 DTLS-SRTP）が、SRTP の鍵材料を導出します。 |
| DTLS の役割 | 手動シグナリングでは、役割は a=setup から決まります（オファー側は passive、アンサー側は active）。IsDTLSClient が確定後にそれを報告します。 |
| SRTP 保護プロファイル | SRTP_AES128_CM_SHA1_80、SRTP_AES128_CM_SHA1_32、SRTP_AEAD_AES_128_GCM、SRTP_AEAD_AES_256_GCM。DTLS ハンドシェイク中にネゴシエートされます。 |
| SSRC ごとの暗号状態 | RFC 3711 3.2.3 節が要求する通り、SSRC ごとに 1 つの暗号コンテキスト（ロールオーバーカウンター、リプレイウィンドウ）を持ちます。BUNDLE によってすべての m 行が 1 つの DTLS-SRTP トランスポートにまとめられる場合でも同様です。 |
| 適用範囲 | RTP/RTCP メディアと、データチャネルを運ぶ SCTP アソシエーションの両方をカバーします。1 つの m 行だけでなく、コネクション全体です。 |
| バックエンド | OpenSSL による SRTP 実装です。 |
Google Congestion Control 方式の遅延ベースの推定器がリンクを追跡し、映像エンコーダーの目標ビットレートを制御します。
| 機能 | メンバー | 備考 |
|---|---|---|
| 遅延ベースの推定器 | TsgcBWE_Estimator | パケットを 5 ms の送信バーストにグループ化し、グループ間の遅延に対してトレンドラインフィルターを実行し、リンクを normal、overuse、underuse に分類します。 |
| レート制御 | AIMD コントローラー | overuse では確認済みレートの 85% まで低下し、underuse では維持し、normal では増加します（直近の既知の上限から遠いときは乗法的に、近いときは加法的に）。 |
| 損失時の上限 | 損失率の追跡 | 損失率が 10% を超えると上限が下がり、2% を下回ると MaxBitrate まで毎秒 8% ずつ回復します。 |
| トランスポート全体のフィードバック | TWCC（RTCP） | BuildRTCP_TWCC / ParseRTCP_TWCC によるトランスポート全体の輻輳制御フィードバックで、それのみに対応するピア向けのフォールバック上限として REMB も備えます。 |
| 有効化 | RTCOptions.Media.CongestionControl | リモートディスクリプションが対応するヘッダー拡張・フィードバックもネゴシエートした場合にのみ有効になります。 |
| 損失の回復 | RTCOptions.Media.RTX | RTCP NACK を受けての、RFC 4588 による映像ストリームの再送です。 |
| 前方誤り訂正 | RTCOptions.Media.FEC | 送信映像ストリームに対する RED / ULPFEC 保護です。 |
| ペーシング | RTCOptions.Media.Pacing | 送信映像パケットを、バーストさせるのではなく推定ビットレートでペース配分します。 |
| キーフレームの回復 | RTCP PLI | 受信側トラックでの RequestKeyFrame が、損失後に送信側へ新しいキーフレームを要求します。 |