:Spesifikasi protokol signaling RTS

Proses signaling

Gambar berikut menunjukkan proses signaling.

Proses signaling

1. Klien mengirim permintaan dengan penawaran Session Description Protocol (SDP).

   1. Buat objek RTCPeerConnection pada klien, tentukan apakah akan menerima atau mengirim sinyal audio dan video, lalu buat penawaran SDP.

      // Tentukan apakah akan menerima atau mengirim sinyal audio dan video.
      { offerToReceiveVideo: true, offerToReceiveAudio: true }

   2. Kirim permintaan penarikan aliran dari klien ke ApsaraVideo Live menggunakan metode HTTPS POST. Badan permintaan berupa string JSON. Untuk informasi lebih lanjut mengenai parameter permintaan, lihat bagian Definisi protokol signaling RTS dalam topik ini.

      Catatan

      • Parameter version menentukan versi protokol signaling RTS. Tetapkan nilainya ke 2.

      • Parameter sdk_version menentukan versi SDK RTS. Anda dapat menetapkan parameter ini sesuai kebutuhan.

   3. Kirim permintaan yang telah dikonstruksi ke ApsaraVideo Live berdasarkan URL signaling menggunakan metode POST. Tentukan URL sumber dalam badan permintaan berformat JSON.

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

      Catatan

      Konten URL signaling pada dasarnya sama dengan URL sumber, kecuali header protokolnya. Contoh URL sebagai berikut:

      • URL signaling: https://domain/app/streamname?auth=xxx

      • URL sumber: artc://domain/app/streamname?auth=xxx

2. Server mengembalikan tanggapan dengan jawaban SDP.

   Setelah server ApsaraVideo Live memverifikasi permintaan, server menghasilkan jawaban SDP dan mengembalikan tanggapan yang berisi informasi mengenai node live streaming kepada klien. Untuk informasi lebih lanjut mengenai parameter respons, lihat bagian Definisi protokol signaling RTS dalam topik ini.

3. Klien memulai Interactive Connectivity Establishment (ICE).

   1. Setelah klien menerima tanggapan berisi jawaban SDP, tetapkan deskripsi sesi dalam objek RTCPeerConnection.

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

   2. Gunakan objek RTCPeerConnection untuk memulai ICE dan enkripsi Datagram Transport Layer Security (DTLS). Setelah saluran signaling terbentuk, klien dapat menarik aliran dari ApsaraVideo Live. Dengan demikian, Anda dapat menerapkan penarikan dan pemutaran aliran berdasarkan standar WebRTC.

4. Klien memulai pemutusan koneksi.

   Klien mengirim pesan alert DTLS yang memulai pemutusan koneksi untuk menghentikan ingest atau pemutaran aliran.

   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

Contoh kode untuk pemutar HTML5

// Buat koneksi peer dan penawaran SDP lokal.
peerConnection = new RTCPeerConnection();
peerConnection.onicecandidate = iceCandidateCallback;
peerConnection.ontrack = remoteStreamCallback;
peerConnection.createOffer({ offerToReceiveVideo: true, offerToReceiveAudio: true })
      .then(signaling_pull).catch(errorHandler);


// Permintaan penarikan aliran live CDN.
function signaling_pull(offer_sdp) {
  console.log('local offer sdp', offer_sdp);

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

    // Tambahkan versi SDK dan protokol.
    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);
}

Definisi protokol signaling RTS

Protokol signaling RTS membentuk koneksi singkat berbasis HTTPS dan menggunakan pesan dalam format JSON. Bagian ini menjelaskan permintaan, respons, dan kode kesalahan berdasarkan protokol signaling RTS.

Contoh permintaan

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"
    }
}

Contoh respons sukses

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"
    }
}

Negosiasi SDP yang ditingkatkan

Pesan dipertukarkan dalam format SDP selama signaling. Negosiasi SDP umumnya mengacu pada RFC 4566. RTS memperluas semantik lebih lanjut agar negosiasi kompatibel dengan karakteristik industri live streaming. RTS mendukung lebih banyak format kontainer video dan audio serta lebih banyak protokol komunikasi, sehingga mengatasi keterbatasan WebRTC yang hanya mendukung format Opus untuk audio dan tidak mendukung B-frame. Dengan demikian, RTS memenuhi kebutuhan protokol streaming yang terus berkembang.

Dukungan audio AAC

RTS dapat mentransmisikan audio dalam berbagai format AAC melalui RTMP, termasuk AAC-LC, HE-AACv1, dan HE-AACv2. Untuk informasi lebih lanjut mengenai format AAC, lihat ISO IEC 14496-3.

RTS dapat mentransmisikan audio dalam format AAC menggunakan format kontainer Low-overhead MPEG-4 Audio Transport Multiplex (LATM). LATM menentukan apakah informasi pengkodean audio dikirim secara in-band atau out-of-band berdasarkan ada tidaknya informasi pengkodean dalam aliran audio. Transmisi in-band mengirim informasi pengkodean untuk setiap frame audio, sedangkan transmisi out-of-band hanya mengirim informasi tersebut sekali saja. Parameter muxconfigPresent dalam array AudioMuxElement menentukan apakah informasi dalam AudioSpecificConfig dikirim secara in-band atau out-of-band. Oleh karena itu, LATM lebih fleksibel dibandingkan Audio Data Transport Stream (ADTS). Jika informasi dalam AudioSpecificConfig tidak berubah, informasi dalam StreamMuxConfig dapat dikirim terlebih dahulu dalam pesan SDP.

Selama signaling, RTS mengurai informasi pengkodean saat ingest aliran audio dan mengembalikan informasi yang telah diurai dalam respons negosiasi, seperti yang ditunjukkan dalam kode berikut.

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

Jika SBR-enabled=1 ditambahkan dalam atribut fmtp MP4A-LATM, format AAC-nya adalah AAC-HE. Jika SBR-enabled=1 dan PS-enabled=1 ditambahkan, format AAC-nya menjadi HE-AACv2. Format AAC berevolusi dari AAC-LC hingga HE-AACv2, sehingga bidang SBR dan PS dapat digunakan dalam atribut fmtp untuk menunjukkan format AAC yang sesuai. Selain itu, Anda dapat menambahkan config=StreamMuxConfig dalam atribut fmtp. StreamMuxConfig diperoleh dari AudioSpecificConfig aliran yang diingest dan berisi parameter terkait detail informasi pengkodean, yang dapat diakses oleh klien sesuai kebutuhan.

Untuk informasi lebih lanjut, lihat Parameter Pengkode AAC-LC / HE-AACv1 / HE-AACv2.

Dukungan video H.265

RTS mengurai informasi pengkodean video dalam format H.264 atau H.265 selama ingest aliran dan mengembalikan informasi video dalam format H.264 atau H.265 dalam jawaban SDP.

a=rtpmap:102 H265/90000

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

Dukungan video yang mengandung B-frame

Selama signaling, klien dapat menambahkan bidang dalam penawaran SDP untuk menentukan apakah akan mendekode video yang mengandung B-frame. Misalnya, jika klien menambahkan BFrame-enabled = 1 dalam atribut fmtp, klien dapat mendekode video yang mengandung B-frame. Dalam kasus ini, RTP timestamp = PTS dapat ditambahkan, yang berarti klien mendekode setiap frame berdasarkan nomor urut yang meningkat. Jika video yang mengandung B-frame tidak didukung, RTS dapat melakukan transkode aliran sumber untuk menghapus B-frame.

Selain itu, server dapat mengembalikan timestamp pencampuran (CTS). Hal ini memungkinkan klien menghitung decoding timestamp (DTS) berdasarkan rumus berikut: Presentation timestamp (PTS) = DTS + CTS. Jika penawaran SDP berisi a=extmap:{$id} uri:webrtc:rtc:rtp-hdrext:video:CompositionTime, RTS menambahkan extension identifier = {$id} ke paket Real-time Transport Protocol (RTP) pertama dari setiap frame video. Nilai variabel id ditentukan oleh penawaran SDP yang dikirim oleh klien. Contoh berikut menunjukkan sebagian isi penawaran SDP dan hasil pengambilan paket selama penarikan aliran:

Cuplikan penawaran SDP (baris 87 adalah header ekstensi 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 memungkinkan klien menentukan apakah akan mendekode video yang mengandung B-frame dan apakah akan mengembalikan informasi CTS, sehingga memastikan interoperabilitas dalam komunikasi.

Mekanisme MSID

Untuk informasi lebih lanjut mengenai MSID, lihat The Msid Mechanism.