:RTS シグナリングプロトкоルの仕様

シグナリングプロセス

次の図は、シグナリングプロセスを示しています。

シグナリングプロセス

1. クライアントが Session Description Protocol (SDP) オファーを含むリクエストを送信します。

   1. クライアントで RTCPeerConnection オブジェクトを作成し、音声および映像シグナルを受信するか送信するかを指定した後、SDP オファーを作成します。

      // 音声および映像シグナルを受信するか送信するかを指定します。
      { offerToReceiveVideo: true, offerToReceiveAudio: true }

   2. HTTPS POST メソッドを使用して、クライアントから ApsaraVideo Live にストリームプルリクエストを送信します。リクエストボディは JSON 文字列です。リクエストパラメーターの詳細については、このトピックの「RTS シグナリングプロトкоルの定義」セクションを参照してください。

      説明

      • version パラメーターは、RTS シグナリングプロトкоルのバージョンを指定します。値は 2 に設定します。

      • sdk_version パラメーターは、RTS SDK のバージョンを指定します。必要に応じて設定できます。

   3. POST メソッドを使用して、シグナリング URL に基づくリクエストを ApsaraVideo Live に送信します。JSON 形式のリクエストボディでソース URL を指定します。

      POST /app/streamname?auth=xxx HTTP/1.1
      Host: domain
      Connection: keep-alive
      Content-Length: 2205
      Content-Type: application/json

      説明

      シグナリング URL の内容は、プロトコルヘッダーを除き、基本的にソース URL と同一です。次に URL の例を示します。

      • シグナリング URL：https://domain/app/streamname?auth=xxx

      • ソース URL：artc://domain/app/streamname?auth=xxx

2. サーバーが SDP アンサーを含むレスポンスを返します。

   ApsaraVideo Live のサーバーがリクエストを検証した後、サーバーは SDP アンサーを生成し、ライブストリーミングノードに関する情報を含むレスポンスをクライアントに返します。レスポンスパラメーターの詳細については、このトピックの「RTS シグナリングプロトкоルの定義」セクションを参照してください。

3. クライアントがインタラクティブ接続確立 (ICE) を開始します。

   1. クライアントが SDP アンサーを含むレスポンスを受信した後、RTCPeerConnection オブジェクトにセッション記述を設定します。

      peerConnection.setRemoteDescription(new RTCSessionDescription(answer.jsep));

   2. RTCPeerConnection オブジェクトを使用して、ICE とデータグラムトランスポート層セキュリティ (DTLS) 暗号化を開始します。シグナリングチャネルが確立されると、クライアントは ApsaraVideo Live からストリームをプルできます。これにより、WebRTC の標準に基づいてストリームのプルと再生を実装できます。

4. クライアントが切断を開始します。

   クライアントは、切断を開始する DTLS アラートメッセージを送信して、ストリームインジェストまたは再生を停止します。

   Datagram Transport Layer Security
     DTLSv1.2 Record Layer: Encrypted Alert
       Content Type: Alert (21)
       Version: DTLS 1.2 (0xfefd)
       Epoch: 1
       Sequence Number: 1
       Length: 26
       Alert Message: Encrypted Alert

HTML5 プレーヤーのサンプルコード

// ピア接続とローカルの SDP オファーを作成します。
peerConnection = new RTCPeerConnection();
peerConnection.onicecandidate = iceCandidateCallback;
peerConnection.ontrack = remoteStreamCallback;
peerConnection.createOffer({ offerToReceiveVideo: true, offerToReceiveAudio: true })
      .then(signaling_pull).catch(errorHandler);


// ApsaraVideo Live にストリームプルリクエストを POST します。
function signaling_pull(offer_sdp) {
  console.log('local offer sdp', offer_sdp);

  peerConnection.setLocalDescription(offer_sdp).then(function() {
    // プルストリームの URL を取得します。
    var stream_url = $("#stream_url").val();
    console.log("stream url:" , stream_url);

    // SDK とプロトコルのバージョンを追加します。
    var protocol_version = 2;
    var sdk_version = "0.0.1";

    $.ajax({url: stream_url, data: JSON.stringify({
          mode: "live",
          version: protocol_version,
          sdk_version: sdk_version,
          jsep: offer_sdp,
      }),
      type: "post",
      success:function(result){
          var signal = JSON.parse(result);
          peerConnection.setRemoteDescription(new RTCSessionDescription(signal.jsep)).then(function() {
              console.log("get remote answer sdp: ", signal.jsep.sdp);
          }).catch(errorHandler);
      }});
  }).catch(errorHandler);
}

RTS シグナリングプロトкоルの定義

RTS シグナリングプロトコルは、HTTPS に基づいて短期間の接続を確立します。このプロトコルは JSON 形式のメッセージを使用します。このセクションでは、RTS シグナリングプロトコルに基づいて、リクエスト、レスポンス、エラーコードについて説明します。

リクエストのサンプル

Request:
{
    "version":2,
    "sdk_version":"0.0.1",
    "mode":"live",
    "pull_streams":[
        {
            "url":"artc://demo.aliyundoc.com/liveApp****/liveStream****",
            "amsid":[
                "rts audio"
            ],
            "vmsid":[
                "rts video"
            ]
        }
    ],
    "jsep":{
        "type":"offer",
        "sdp":"v=0\n\ro=- 6839248142876176651 2 IN IP4 127.0.0.1\n\rs=-\n\r Omitted content"
    }
}

成功レスポンスのサンプル

Response:
{
    "trace_id":"2_1591173296_101.227.XX.XX_702080732320_dec327eb6eed0e0b07b349c8a565****",
    "code":200,
    "jsep":{
        "type":"answer",
        "sdp":"v=0\r\no=- 1591173291 2 IN IP4 127.0.0.1\n\r Omitted content"
    }
}

拡張 SDP ネゴシエーション

シグナリング中は、SDP 形式でメッセージが交換されます。SDP ネゴシエーションは、通常RFC 4566に基づきます。RTS は、ライブストリーミング業界の特性に合わせ、ネゴシエーションのセマンティクスを拡張して互換性を確保します。RTS は、より多くの音声および映像コンテナ形式と通信プロトコルをサポートします。これにより、WebRTC が音声で Opus 形式のみをサポートし、B フレームをサポートしないという問題が解決されます。RTS は、増加するストリーミングプロトкоルのニーズに対応します。

AAC 音声のサポート

RTS は、RTMP 経由でさまざまな AAC 形式の音声を伝送できます。AAC 形式には、AAC-LC、HE-AACv1、HE-AACv2 が含まれます。AAC 形式の詳細については、「ISO IEC 14496-3」をご参照ください。

RTS は、Low-overhead MPEG-4 Audio Transport Multiplex (LATM) コンテナ形式を使用して、AAC 形式の音声を伝送できます。LATM は、音声にエンコード情報が含まれているかどうかに基づいて、音声のエンコード情報をインバンドまたはアウトオブバンドで伝送するかを判断します。インバンド伝送では、各音声フレームに対してエンコード情報を送信します。アウトオブバンド伝送では、エンコード情報を 1 回だけ送信します。AudioMuxElement 配列内の muxconfigPresent パラメーターは、AudioSpecificConfig の情報をインバンドまたはアウトオブバンドで伝送するかを指定します。このため、LATM は Audio Data Transport Stream (ADTS) よりも柔軟です。AudioSpecificConfig の情報が変更されない場合、StreamMuxConfig の情報は SDP メッセージで最初に伝送できます。

シグナリング中、RTS は音声ストリームインジェスト時にエンコード情報を解析し、その結果をネゴシエーションレスポンスで返します。次のコードを参照してください。

m=audio 9 UDP/RTP/AVPF 120 96 
a=rtpmap:120 MP4A-LATM/44100/2

AudioSpecificConfig = 0x1210

AudioSpecificConfig = 2b920800

AudioSpecificConfig = eb8a0800

a=rtpmap:120 MP4A-LATM/44100/2
a=fmtp:120 cpresent=0;profile-level-id=1;object=2;config=400024203fc0

a=rtpmap:120 MP4A-LATM/44100/2 
a=fmtp:120 cpresent=0;profile-level-id=1;object=2;config=4000572410003fc0;SBR-enabled=1

a=rtpmap:120 MP4A-LATM/44100/2 
a=fmtp:120 cpresent=0;object=2;profile-level-id=1;config=4001d71410003fc0;PS-enabled=1;SBR-enabled=1

MP4A-LATM の fmtp 属性にSBR-enabled=1が追加されている場合、AAC 形式は AAC-HE です。SBR-enabled=1とPS-enabled=1の両方が追加されている場合、AAC 形式は HE-AACv2 です。AAC 形式は AAC-LC から HE-AACv2 へと進化します。そのため、fmtp 属性の SBR および PS フィールドを使用して AAC 形式を示すことができます。また、fmtp 属性にconfig=StreamMuxConfigを追加できます。StreamMuxConfig は、インジェストされたストリームの AudioSpecificConfig から取得され、エンコード情報の詳細に関連するパラメーターを含みます。クライアントは必要に応じて詳細を取得できます。

詳細については、「AAC-LC / HE-AACv1 / HE-AACv2 Encoder Parameters」をご参照ください。

H.265 映像のサポート

RTS は、ストリームインジェスト時に H.264 または H.265 形式の映像のエンコード情報を解析し、SDP アンサーでH.264またはH.265形式の映像情報を返します。

a=rtpmap:102 H265/90000

a=rtpmap:122 H265/90000
a=fmtp:122

B フレームを含む映像のサポート

シグナリング中、クライアントは SDP オファーにフィールドを追加して、B フレームを含む映像をデコードするかどうかを指定できます。たとえば、クライアントが fmtp 属性にBFrame-enabled = 1を追加すると、B フレームを含む映像をデコードできます。この場合、RTP timestamp = PTSを追加できます。これは、クライアントが増加するシーケンス番号に基づいて各フレームをデコードすることを意味します。B フレームを含む映像がサポートされない場合、RTS はソースストリームをトランスコードして B フレームを削除できます。

また、サーバーはコンポジションタイムスタンプ (CTS) を返すことができます。これにより、クライアントは次の式に基づいてデコードタイムスタンプ (DTS) を計算できます：プレゼンテーションタイムスタンプ (PTS) = DTS + CTS。SDP オファーにa=extmap:{$id} uri:webrtc:rtc:rtp-hdrext:video:CompositionTimeが含まれている場合、RTS は各映像フレームの最初の Real-time Transport Protocol (RTP) パケットに拡張識別子 = {$id}を追加します。id 変数の値は、クライアントが送信する SDP オファーによって決まります。次の例は、SDP オファーの一部と、ストリームプル中のパケットキャプチャを示しています。

SDP オファーのスニペット (87 行目が CompositionTime 拡張ヘッダー)：

a=extmap:10 uri:webrtc:rtc:rtp-hdrext:video:CompositionTime
a=extmap:12 http://www.wxxx
a=extmap:13 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:20 urn:realx:stream-start-info
a=extmap:59 urn:realx:frame-descriptor-00

Header extensions
  RFC 5285 Header Extension (Two-Byte Header)
      Application Bits: 0
      Identifier: 5
      Length: 2
      Extension Data: 0003
  RFC 5285 Header Extension (Two-Byte Header)
      Application Bits: 0
      Identifier: 19
      Length: 3
      Extension Data: 000050
H.264

RTS では、クライアントが B フレームを含む映像をデコードするかどうか、および CTS 情報を返すかどうかを判断できるようになります。これにより、通信における汎用性が確保されます。

MSID メカニズム

MSID の詳細については、「The Msid Mechanism」をご参照ください。