:Especificações do protocolo de sinalização RTS

Processo de sinalização

A figura a seguir ilustra o processo de sinalização.

Processo de sinalização

1. O cliente envia uma solicitação com uma oferta Session Description Protocol (SDP).

   1. Crie um objeto RTCPeerConnection no cliente, especifique se deseja receber ou enviar sinais de áudio e vídeo e crie uma oferta SDP.

      // Specify whether to receive or send audio and video signals.
      { offerToReceiveVideo: true, offerToReceiveAudio: true }

   2. Envie uma solicitação de pull de stream do cliente para o ApsaraVideo Live pelo método HTTPS POST. O corpo da solicitação é uma string JSON. Para obter mais informações sobre os parâmetros da solicitação, consulte a seção Definição do protocolo de sinalização RTS deste tópico.

      Nota

      • O parâmetro version especifica a versão do protocolo de sinalização RTS. Defina o valor como 2.

      • O parâmetro sdk_version indica a versão do RTS SDK. Defina esse parâmetro conforme necessário.

   3. Envie a solicitação construída para o ApsaraVideo Live com base na URL de sinalização pelo método POST. Especifique a URL de source no corpo da solicitação em formato JSON.

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

      Nota

      O conteúdo de uma URL de sinalização é praticamente idêntico ao de uma URL de source, exceto pelo cabeçalho do protocolo. Os exemplos a seguir ilustram essas URLs:

      • URL de sinalização: https://domain/app/streamname?auth=xxx

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

2. O servidor retorna uma resposta com uma answer SDP.

   Após validar a solicitação, o servidor do ApsaraVideo Live gera uma answer SDP e devolve ao cliente uma resposta com informações sobre o nó de transmissão ao vivo. Para obter mais detalhes sobre os parâmetros de resposta, consulte a seção Definição do protocolo de sinalização RTS deste tópico.

3. O cliente inicia o Interactive Connectivity Establishment (ICE).

   1. Após receber a resposta com a answer SDP, especifique a descrição da sessão no objeto RTCPeerConnection.

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

   2. Use o objeto RTCPeerConnection para iniciar o ICE e a criptografia Datagram Transport Layer Security (DTLS). Após estabelecer o canal de sinalização, o cliente poderá fazer pull de streams do ApsaraVideo Live. Assim, você implementa o pull e a reprodução de streams seguindo os padrões WebRTC.

4. O cliente inicia a desconexão.

   O cliente envia uma mensagem de alerta DTLS para iniciar a desconexão e interromper o ingest ou a reprodução do stream.

   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

Exemplo de código para o player 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);
}

Definição do protocolo de sinalização RTS

O protocolo de sinalização RTS estabelece uma conexão de curta duração baseada em HTTPS e utiliza mensagens no formato JSON. Esta seção descreve a solicitação, a resposta e os códigos de erro desse protocolo.

Exemplo de solicitação

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

Exemplo de resposta de sucesso

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

Negociação SDP aprimorada

A sinalização troca mensagens no formato SDP. A negociação SDP geralmente segue a RFC 4566. O RTS expande a semântica para compatibilizar a negociação com as características do setor de transmissão ao vivo. Ele suporta mais formatos de contêiner para vídeo e áudio, além de diversos protocolos de comunicação. Assim, o RTS resolve limitações do WebRTC, como o suporte apenas ao formato Opus para áudio e a falta de suporte a B-frames, atendendo à crescente demanda por protocolos de streaming.

Suporte a áudio AAC

O RTS transmite áudio em vários formatos AAC via RTMP, incluindo AAC-LC, HE-AACv1 e HE-AACv2. Para obter mais informações sobre formatos AAC, consulte ISO IEC 14496-3.

A transmissão de áudio em formatos AAC ocorre pelo formato de contêiner Low-overhead MPEG-4 Audio Transport Multiplex (LATM). O LATM determina se as informações de codificação do áudio são transmitidas em modo in-band ou out-of-band, dependendo da presença dessas informações no fluxo de áudio. A transmissão in-band envia as informações de codificação para cada quadro de áudio; já a transmissão out-of-band as envia apenas uma vez. O parâmetro muxconfigPresent em um array AudioMuxElement define se as informações do AudioSpecificConfig são transmitidas em modo in-band ou out-of-band. Por isso, o LATM oferece maior flexibilidade que o Audio Data Transport Stream (ADTS). Se as informações no AudioSpecificConfig permanecerem inalteradas, os dados do StreamMuxConfig podem ser transmitidos inicialmente em uma mensagem SDP.

Durante a sinalização, o RTS analisa as informações de codificação no ingest do stream de áudio e retorna os dados analisados na resposta de negociação, conforme mostra o código a seguir.

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

Se SBR-enabled=1 for adicionado ao atributo fmtp do MP4A-LATM, o formato AAC será AAC-HE. Caso tanto SBR-enabled=1 quanto PS-enabled=1 estejam presentes, o formato será HE-AACv2. Como o formato AAC evolui de AAC-LC para HE-AACv2, os campos SBR e PS no atributo fmtp indicam as variações do formato. Além disso, é possível adicionar config=StreamMuxConfig no atributo fmtp. O StreamMuxConfig é obtido do AudioSpecificConfig do stream ingerido e contém parâmetros relacionados aos detalhes das informações de codificação, permitindo que o cliente obtenha esses dados conforme necessário.

Para obter mais informações, consulte AAC-LC / HE-AACv1 / HE-AACv2 Encoder Parameters.

Suporte a vídeos H.265

O RTS analisa as informações de codificação de vídeos nos formatos H.264 ou H.265 durante o ingest e retorna os dados correspondentes no formato H.264 ou H.265 na resposta SDP.

a=rtpmap:102 H265/90000

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

Suporte a vídeos com B-frames

Durante a sinalização, o cliente pode adicionar um campo na oferta SDP para especificar se deseja decodificar vídeos com B-frames. Por exemplo, ao incluir BFrame-enabled = 1 no atributo fmtp, o cliente habilita a decodificação desses vídeos. Nesse cenário, é possível adicionar RTP timestamp = PTS, indicando que o cliente decodifica cada quadro com base no número de sequência crescente. Caso não haja suporte a vídeos com B-frames, o RTS pode transcodificar os streams de source para remover os B-frames.

Além disso, o servidor pode retornar um composition timestamp (CTS), permitindo que o cliente calcule o decoding timestamp (DTS) pela fórmula: Presentation timestamp (PTS) = DTS + CTS. Se uma oferta SDP contiver a=extmap:{$id} uri:webrtc:rtc:rtp-hdrext:video:CompositionTime, o RTS adiciona extension identifier = {$id} ao primeiro pacote Real-time Transport Protocol (RTP) de cada quadro de vídeo. O valor da variável id depende da oferta SDP enviada pelo cliente. Os exemplos abaixo mostram parte do conteúdo da oferta SDP e a captura de pacotes durante o pull do stream:

Trecho da oferta SDP (a linha 87 corresponde ao cabeçalho de extensão 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

O RTS permite que o cliente decida se deseja decodificar vídeos com B-frames e se deve retornar informações de CTS, garantindo capacidades gerais de comunicação.

Mecanismo MSID

Para obter mais informações sobre o MSID, consulte The Msid Mechanism.