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

シグナリングプロセス

次の図は、シグナリング処理を示しています。

シグナリングプロセス

1. クライアントは、セッション記述プロトコル (SDP) オファーと共に要求を送信します。

   1. クライアントでRTCPeerConnectionオブジェクトを作成し、オーディオおよびビデオ信号を受信するか送信するかを指定してから、SDPオファーを作成します。

      // Specify whether to receive or send audio and video signals.
      { 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 (Interactive Connectivity Establishment) を開始します。

   1. クライアントがSDP回答を含む応答を受信した後、RTCPeerConnectionオブジェクトでセッション記述を指定します。

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

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

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

   クライアントは、ストリームの取り込みまたは再生を停止するために切断を開始するDTLS警告メッセージを送信します。

   

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

// Create peer connection and local offer sdp.
peerConnection = new RTCPeerConnection();
peerConnection.onicecandidate = iceCandidateCallback;
peerConnection.ontrack = remoteStreamCallback;
peerConnection.createOffer({ offerToReceiveVideo: true, offerToReceiveAudio: true })
      .then(signaling_pull).catch(errorHandler);


// CDN live post pull stream request.
function signaling_pull(offer_sdp) {
  console.log('local offer sdp', offer_sdp);

  peerConnection.setLocalDescription(offer_sdp).then(function() {
    // Get pull stream url.
    var stream_url = $("#stream_url").val();
    console.log("stream url:" , stream_url);

    // Add sdk and protocol versions.
    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:description,
      }),
      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は、ビデオとオーディオのより多くのコンテナ形式と、より多くの通信プロトコルをサポートします。 このように、RTSは、WebRTCがオーディオのOpus形式のみをサポートし、Bフレームをサポートしないという問題を解決します。 RTSは、増加するストリーミングプロトコルのニーズを満たします。

AACオーディオ対応

RTSは、RTMPを介してさまざまなAAC形式でオーディオを送信できます。 AACフォーマットは、AAC-LC、HE-AACv1、およびHE-AACv2を含みます。 AACフォーマットの詳細については、「ISO IEC 14496-3」をご参照ください。

RTSは、低オーバーヘッドMPEG-4オーディオトランスポート多重 (LATM) コンテナフォーマットを使用して、AACフォーマットでオーディオを送信できます。 LATMは、オーディオが符号化情報を含むかどうかに基づいて、オーディオに関する符号化情報が帯域内モードで送信されるか帯域外モードで送信されるかを決定します。 帯域内伝送は、各オーディオフレームの符号化情報を送信します。 帯域外伝送は、符号化情報を一度だけ送信します。 AudioMuxElement配列内のmuxconfigPresentパラメータは、AudioSpecificConfig内の情報が帯域内モードで送信されるか帯域外モードで送信されるかを指定します。 したがって、LATMは、オーディオデータ転送ストリーム (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エンコーダパラメータ」をご参照ください。

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フレームを含むビデオがサポート

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

さらに、サーバは、構成タイムスタンプ (CTS) を返すことができます。 これにより、クライアントは、以下の式に基づいて復号タイムスタンプ (DTS) を計算することができます。 SDPオファーがa=extmap:{$id} uri:webrtc:rtp-hdrext:video:CompositionTimeを含む場合、RTSはextension identifier = {$id} を各ビデオフレームの最初のリアルタイムトランスポートプロトコル (RTP) パケットに追加します。 id変数の値は、クライアントによって送信されるSDPオファーによって決定されます。 次の図は、ストリームプル中のSDPオファーとパケットキャプチャの部分的なコンテンツを示しています。

RTSにより、クライアントは、Bフレームを含むビデオをデコードするかどうか、およびCTS情報を返すかどうかを判断できます。 これは、通信における一般的な能力を保証します。

MSIDメカニズム

MSIDの詳細については、「Msidメカニズム」をご参照ください。