Visão geral da criação de sessões

Ao se conectar a uma sessão do OpenTok em um aplicativo, você especifica a sessão à qual deseja se conectar usando um ID de sessão do OpenTok. Cada ID de sessão identifica uma sessão exclusiva do OpenTok. Você pode pensar em uma sessão como uma sala na qual os participantes se reúnem e conversam.

O número de sessões que você cria e a forma como os usuários se conectam a elas dependem dos requisitos do seu aplicativo. Se seu aplicativo conectar usuários entre si para uma reunião única, crie uma sessão exclusiva para essa reunião. No entanto, se seu aplicativo conectar usuários ao longo de vários dias na mesma “sala”, você pode criar uma única sessão e reutilizá-la. Se um grupo de usuários se reunir, enquanto outros grupos se reúnem independentemente, crie sessões exclusivas para cada grupo.

As sessões do OpenTok não expiram. No entanto, os tokens de autenticação expiram. Observe também que as sessões não podem ser encerradas explicitamente.

Ao criar uma sessão, você pode especificar as seguintes opções, descritas nas seções a seguir:

  • O modo de mídia (se deve ou não utilizar o OpenTok Media Router)
  • A preferência de arquivamento (se a sessão deve ser arquivada automaticamente)
  • Uma sugestão de localização (para especificar a geolocalização da sessão)

O OpenTok Media Router e os modos de mídia

Ao criar uma sessão, você especifica como os clientes nessa sessão enviarão fluxos de áudio e vídeo, conhecidos como modo de mídia. Existem duas opções:

  • Repassado — Em uma sessão retransmitida, os clientes tentarão enviar fluxos de áudio e vídeo diretamente entre si (ponto a ponto). No entanto, se os clientes não conseguirem se conectar devido a restrições de firewall, a sessão utilizará o servidor TURN da OpenTok para retransmitir os fluxos de áudio e vídeo. (Antes da versão 2.2, os SDKs do servidor OpenTok se referiam a essas sessões como sessões ponto a ponto. No entanto, mesmo ao usar esses SDKs, as sessões ainda utilizarão o servidor TURN do OpenTok para retransmitir os fluxos caso restrições de firewall bloqueiem a transmissão ponto a ponto). O TLS 1.3 e um certificado forte de pelo menos 3.072 bits são utilizados para a negociação da sessão.

  • Encaminhado — A sessão utiliza o OpenTok Media Router para encaminhar fluxos de áudio e vídeo entre os clientes. O Roteador de mídia OpenTok oferece os seguintes benefícios:

    • O TLS 1.3 e um certificado forte de pelo menos 3.072 bits são utilizados para a negociação da sessão.

    • O OpenTok Media Router pode reduzir o uso de largura de banda em sessões com vários participantes. (Quando a propriedade “media mode” está definida como “relayed”, cada cliente que publica um fluxo deve enviá-lo separadamente para cada cliente que o assina. Com o OpenTok Media Router, um emissor envia um único fluxo uma vez para o roteador, e este o encaminha para cada cliente assinante.)

    • O OpenTok Media Router pode melhorar a qualidade da experiência do usuário por meio de Solução alternativa de áudio e recuperação de vídeo para assinantes. Com esses recursos, se a conectividade de um cliente se deteriorar a ponto de não suportar o vídeo de uma transmissão à qual ele está inscrito, o vídeo é interrompido nesse cliente (sem afetar os demais clientes), e o cliente passa a receber apenas o áudio. Se a conectividade do cliente melhorar, o vídeo é restabelecido.

    • O OpenTok Media Router é compatível com o Recurso de arquivamento do OpenTok, que permite gravar, salvar e recuperar sessões do OpenTok.

    • O OpenTok Media Router oferece suporte a transmissões ao vivo.

    • O OpenTok Media Router oferece suporte a Experiência com o Composer.

    • Em sessões que utilizam o OpenTok Media Router, diminuir a taxa de quadros de um vídeo publicado reduz proporcionalmente a largura de banda utilizada pela transmissão.

    • O OpenTok Media Router é compatível com o recurso de vídeo escalável. O vídeo escalável pode melhorar significativamente a qualidade do vídeo em sessões com vários participantes.

    • Nos clientes que utilizam os SDKs do OpenTok para iOS e Android, as sessões retransmitidas suportam apenas dois clientes conectados à sessão. O OpenTok Media Router suporta clientes adicionais para sessões com múltiplos participantes em dispositivos móveis.

    • O OpenTok Media Router é compatível com o Recurso de interconexão SIP, que permite conectar sessões do OpenTok a gateways SIP.

    • O OpenTok Media Router é compatível com o Recurso de conector de áudio, que permite enviar áudio de uma sessão do OpenTok para um WebSocket.

As sessões roteadas (sessões que utilizam o OpenTok Media Router) também se beneficiam das seguintes otimizações:

  • Conexão com um único par. A partir da versão 2.28.0 dos SDKs de cliente para iOS, Android, Windows, macOS e Linux, as sessões roteadas oferecerão suporte a conexão com um único par. Com a conexão de par único ativada, todos os fluxos de assinantes de um cliente são transmitidos por meio de uma única conexão com o OpenTok Media Router (mesmo que sejam publicados por clientes diferentes). Os benefícios de habilitar a conexão com um único par incluem menor consumo de recursos do cliente, melhor controle de taxa e, no caso de dispositivos móveis nativos, suporte para sessões maiores. Quando a conexão com um único par está desativada (configuração padrão), o cliente usará uma conexão separada com o OpenTok Media Router para cada pacote de áudio/vídeo.

    A conexão com um único par está disponível apenas em sessões roteadas (sessões que utilizam o Media Router da Video API da Vonage). Para obter um guia completo, incluindo casos de uso, detalhes de configuração, exemplos de código e interação com outros recursos, consulte o Guia do desenvolvedor para conexão com um único par.

    Para habilitar a conexão com um único par, utilize as seguintes APIs do Client SDK:

    • Web SDK (OpenTok.js) — Consulte o singlePeerConnection propriedade das opções que você passa para OT.initSession()
    • SDK do Android — Session.Builder.setSinglePeerConnection()
    • SDK do iOS — OTSessionSettings.singlePeerConnection
    • SDK do Linux — otc_session_settings_set_single_peer_connection()
    • SDK do macOS — otc_session_settings_set_single_peer_connection()
    • SDK do Windows — SinglePeerConnection propriedade do Session.Builder classe
    • SDK do React Native — O enableSinglePeerConnection propriedade do options propriedade do componente OTSession

  • Otimização da rede de mídia. A plataforma utiliza o Media Mesh para otimizar automaticamente as sessões roteadas, conectando cada participante ao roteador de mídia no data center regional mais próximo. Isso reduz a latência e melhora a qualidade, especialmente em sessões geograficamente distribuídas.

    O Media Mesh está habilitado por padrão e não requer configuração. Para anular essa otimização e restringir a mídia a uma região específica, consulte Zonas de mídia regionais.

  • Roteamento adaptativo de mídia. A partir do OpenTok.js v2.24.7 e das versões v2.27.0 dos demais SDKs de cliente (para Android, iOS, Windows, macOS, Linux e React), as sessões roteadas foram otimizadas para usar roteamento adaptativo de mídia, se possível. O roteamento adaptativo de mídia determina se a mídia pode ser retransmitida sem o OpenTok Media Router para transmissões de vídeo um a um, a fim de otimizar o desempenho da mídia entre dois participantes. A sessão roteada adapta automaticamente o roteamento de mídia para usar o OpenTok Media Router quando necessário — para sessões com três ou mais participantes, arquivamento, transmissões ao vivo, interconexão SIP, Experience Composer, Live Captions e Audio Connector.

    Com a adição do roteamento adaptativo de mídia, há também um scalableVideo opção no OpenTok.js OT.initPublisher() método, para substituir a configuração padrão e desativar o vídeo escalável para o editor em uma sessão roteada.

Roteamento adaptativo de mídia

O roteamento adaptativo de mídia (AMR) é uma otimização de desempenho para sessões encaminhadas. A AMR avalia o número de assinantes de cada editor individualmente. Quando um editor tem apenas um assinante e nenhum recurso que exija o uso do Media Router está em uso (por exemplo, arquivamento, transmissão ao vivo, SIP etc.), a plataforma retransmite a mídia desse editor em modo ponto a ponto para o assinante, em vez de roteá-la pelo Media Router. Isso reduz a latência e pode melhorar a qualidade do áudio e do vídeo.

A sessão permanece como uma sessão roteada o tempo todo. O AMR não altera o modo de mídia da sessão — ele apenas altera o caminho da mídia utilizado nos bastidores. O código do seu aplicativo, os tokens e a configuração da sessão no lado do servidor permanecem exatamente os mesmos. A alternância entre a retransmissão ponto a ponto e a retransmissão pelo Media Router é gerenciada de forma transparente pelos SDKs do cliente.

Quando o AMR utiliza retransmissão ponto a ponto

O AMR retransmitirá a mídia diretamente entre um editor e seu assinante (contornando o Roteador de Mídia no caminho da mídia) quando todos das seguintes afirmações são verdadeiras:

  • A editora tem exatamente um assinante.
  • Nenhum dos recursos listados na próxima seção está ativo.

Por exemplo, uma sessão com quatro emissores e quatro assinantes pode permanecer inteiramente no modo de retransmissão ponto a ponto, desde que cada emissor tenha apenas um assinante e nenhum recurso do Media Router esteja em uso.

Quando o AMR muda para o Media Router

A plataforma faz com que a mídia de um editor passe pelo Media Router quando qualquer se alguma das seguintes condições se aplicar:

Assim que qualquer gatilho for acionado, todas as mídias dos editores serão encaminhadas de forma integrada pelo Media Router.

Suporte ao SDK

O AMR foi introduzido no OpenTok.js v2.24.7 e na versão 2.27.0 dos Client SDKs para Android, iOS, Windows, macOS, Linux e React. Os clientes que utilizam versões mais antigas do Client SDK em uma sessão roteada sempre usarão o Media Router.

Implicações para a depuração e o desenvolvimento

O AMR é transparente para a lógica do seu aplicativo, mas há alguns aspectos que devem ser levados em consideração durante o desenvolvimento e a resolução de problemas:

  • Inspetor pode apresentar erros clientDisconnection eventos que ocorrem quando a mídia de um editor faz a transição do retransmissor ponto a ponto para o Media Router (por exemplo, quando um segundo cliente se inscreve em um stream). Esses eventos não representam desconexões reais — os participantes permanecem conectados durante toda a transição. Esse é um problema conhecido no Inspector.
  • Os objetos MediaStream podem sofrer alterações durante as transições. Quando o AMR alterna entre o retransmissor ponto a ponto e o Media Router, o MediaStream de um assinante é substituída. Se seu aplicativo acessar MediaStream objetos diretamente (por exemplo, para reproduzir vídeo em um <video> elementos), você deve lidar com essa alteração de uma das seguintes maneiras:
    • Recomendado: Use o API de transmissão de mídia disponível (disponível no OpenTok.js v2.27.7 ou superior). O mediaStreamAvailable O evento nos objetos Publisher e Subscriber leva em conta automaticamente quaisquer alterações causadas pelo AMR, fornecendo o resultado correto MediaStream sempre que ocorre uma transição.
    • Abordagem tradicional (anterior à v2.27.7): Escutar o play evento no elemento de vídeo do Assinante para detectar quando o MediaStream foi substituído; atualize sua renderização personalizada de acordo com isso. Consulte o Acesso a objetos do MediaStream para assinantes guia.
  • Os eventos de conexão e de fluxo continuam sendo disparados normalmente. Você não precisa lidar com as transições de AMR nos seus ouvintes de eventos de sessão. O streamCreated, streamDestroyed, connectionCreated, e connectionDestroyed Os eventos refletem o estado real dos participantes, e não o caminho de mídia subjacente.

Interação com outros recursos

  • Conexão com um único par (SPC): O SPC só fica ativo quando a mídia passa pelo Media Router. Enquanto o AMR estiver retransmitindo a mídia de um editor em modo ponto a ponto, o SPC não se aplica a esse fluxo. Assim que o fluxo passar para o Media Router, o SPC entra em vigor, caso esteja habilitado.
  • Criptografia de ponta a ponta: A criptografia de ponta a ponta funciona com o AMR. A mídia é criptografada, independentemente de ser transmitida ponto a ponto ou por meio do Media Router.
  • Opção alternativa de áudio: Solução alternativa de áudio para assinantes é um recurso do Media Router que normalmente é aplicado assim que um fluxo é roteado pelo Media Router. No entanto, enquanto o AMR está retransmitindo a mídia de um editor em modo ponto a ponto, Opção alternativa de áudio do editor desativar automaticamente o vídeo para proteger o fluxo de áudio, se necessário. Assim que o fluxo for encaminhado para o Media Router, o fallback de áudio tanto do emissor quanto do assinante será aplicado normalmente.
  • Transmissão simultânea e escalabilidade: Enquanto o AMR estiver retransmitindo mídia ponto a ponto, o vídeo escalável é desativado automaticamente, independentemente do codec em uso. Quando o fluxo é transferido para o Media Router, o comportamento do vídeo escalável depende do codec e da configuração de vídeo escalável do aplicativo no painel de controle:
    • VP8: Se o vídeo escalável estiver configurado para Em ou Auto No painel de controle, a transmissão simultânea é ativada automaticamente no trecho roteado assim que ocorre a transição para o Media Router.
    • VP9: O vídeo escalável está habilitado por padrão quando roteado pelo Media Router.
    • H.264: O vídeo escalável não é compatível e permanece desativado por padrão em todos os casos.

Modo de arquivo

Ao criar uma sessão, você pode definir o modo de arquivamento para que a sessão seja arquivada automaticamente. Isso se aplica apenas a sessões roteadas (sessões que utilizam o OpenTok Media Router). Por padrão, as sessões não são arquivadas automaticamente.

Dicas de localização

Ao criar uma sessão, você pode definir o endereço IP que a plataforma de vídeo da Vonage utilizará para selecionar o melhor servidor para controlar a sessão em sua rede global. Se nenhuma indicação de localização for definida ao criar a sessão (o que é recomendado), o servidor de controle da sessão será selecionado com base na localização do primeiro cliente que se conectar à sessão. Defina uma indicação de localização somente se você souber a região geográfica geral (e um endereço IP representativo) e acreditar que o primeiro cliente a se conectar possa não estar nessa região. Especifique um endereço IP que seja representativo da localização geográfica da sessão.

Para a transmissão de mídia, o sistema sempre utilizará a indicação de localização para se conectar ao servidor de mídia (SFU) mais próximo, garantindo que o tráfego de mídia seja roteado pelo servidor mais adequado à localização geográfica do cliente.

Melhores práticas na criação de sessões

Reutilização do ID da sessão

Sempre que possível, não reutilize IDs de sessão entre diferentes conversas de videochamada. Em vez disso, gere novos IDs de sessão para cada videochamada distinta em seu aplicativo.

Isso é importante, especialmente ao usar o OpenTok Inspetor. No Inspector, as pontuações de qualidade das sessões e os dados são indexados por ID de sessão. Um ID de sessão reutilizado em várias conversas é mais difícil de depurar usando o Inspector, e as sessões com IDs reutilizados tendem a apresentar pontuações de qualidade agregadas mais baixas do que a qualidade real da chamada.

Ativar a migração de sessão ou limitar as sessões a 8 horas

O autoescalonamento moderno na nuvem torna necessário estabelecer um tempo mínimo de rotação para os serviços. Quaisquer sessões com duração superior a 8 horas podem ser desconectadas, pois podem estar em serviços que estão passando por um processo de expansão ou contração.

A versão 2.30.0 e as versões posteriores dos SDKs do cliente da Video API da Vonage incluem um recurso de migração de sessão que transfere, de forma contínua, todos os participantes de uma sessão para um novo servidor durante a rotação de servidores. Esse recurso garante a continuidade da sessão com o mínimo de interrupção para os participantes. Consulte Rotação de servidores e migração de sessões.

Observação para clientes que utilizam versões dos SDKs de cliente anteriores à 2.30.0: Recomendamos que, para sessões com duração prevista superior a 8 horas, você migre os usuários conectados para uma nova sessão antes que ocorram eventuais eventos de tempo limite ou reconexão. Isso garantirá a melhor experiência para o usuário.

Os clientes também são desconectados de uma sessão se não publicarem ou se inscreverem em fluxos dentro de 4 horas após a conexão.

Você pode usar monitoramento de sessão para receber notificações quando as sessões forem encerradas ou atingirem o tempo limite e quando estiver programada a rotação de um grupo de servidores da Video API para uma sessão.

Para obter mais informações, consulte Rotação de servidores.

Escolha entre o tipo de sessão “Relayed” e “Routed”

Utilize uma sessão retransmitida em vez de uma sessão roteada, caso haja apenas dois participantes (ou talvez até três) e você não esteja utilizando o arquivamento. O uso de sessões retransmitidas reduz a latência entre os participantes, diminui os pontos de falha e, na maioria dos casos, permite obter melhor qualidade de vídeo e áudio.

As sessões roteadas são obrigatórias caso você queira arquivar sua sessão. Elas são recomendadas se houver mais de dois ou três participantes na sessão.

Para obter mais informações, consulte O OpenTok Media Router e os modos de mídia.

Criação de sessões

Enquanto trabalha em uma versão de teste do seu aplicativo, você pode obter um ID de sessão de teste usando a página do projeto do seu Account da Video API.

Você também pode usar uma das bibliotecas do lado do servidor da OpenTok ou a API REST da OpenTok para gerar uma sessão:

Você também pode usar o API REST do OpenTok para criar uma sessão.

Se você precisar gerar dinamicamente vários IDs de sessão, use uma das bibliotecas do lado do servidor da OpenTok ou a API REST da OpenTok — e não a Página do Projeto.