Roteamento Direto – protocolos de mídia
Este artigo descreve como o Roteamento Direto dá suporte a bypass de mídia com um SBC (Controlador de Borda de Sessão) habilitado para ICE Lite, conforme descrito no RFC 5245. Este artigo destina-se aos administradores de voz responsáveis por configurar a conexão entre o SBC local e o serviço proxy SIP.
Este artigo fornece uma visão geral dos cenários e requisitos do ICE Lite para interoperabilidade. O artigo descreve os formatos de mensagem e as transições necessárias do computador de estado para garantir fluxo de chamada e mídia confiáveis.
Terminologia
Primeiro Olá – As primeiras palavras faladas pelo chamador e pelo chamador. É importante que todos os esforços sejam feitos para garantir que os primeiros pacotes dos pontos de extremidade sejam entregues de forma confiável para a maioria dos casos de uso.
Forking – A oferta do chamador pode ser entregue a vários pontos de extremidade de ponto de extremidade de chamada se o destinatário estiver disponível em vários dispositivos (por exemplo, um usuário do Teams pode estar conectado ao Teams para Windows e Teams para Android ou iPhone).
Resposta Provisória (183) – Os pontos de extremidade do callee para configuração de chamada mais rápida enviam uma resposta com os candidatos e as chaves necessárias para estabelecer o fluxo de mídia. Essa resposta é feita em antecipação ao usuário que potencialmente responde à chamada (200OK) dessa instância específica do callee. Com a bifurcação, o chamador deve estar pronto para receber várias respostas provisórias.
Re-Invite – Oferecer com candidatos finais selecionados pelo ponto de extremidade de controle ICE. Essa oferta tem o atributo a=remote-candidate para resolve quaisquer condições de corrida de lidar com vários garfos.
Ponto de Extremidade do Teams – esse ponto de extremidade pode ser um servidor (Processador de Mídia, Retransmissão de Transporte) ou o cliente do Teams.
Formato de mensagem
A infraestrutura do Teams segue o RFC 5245 para ICE-Lite. Todas as mensagens STUN estão em conformidade com o RFC 5389.
Os SBCs, conforme exigido pelo RFC 5389, devem ignorar todos os atributos STUN que não reconhecem e continuar a processar as mensagens com os atributos conhecidos.
Se algum pacote malformado for recebido, os pacotes deverão ser descartados sem afetar o estabelecimento da sessão de mídia.
Requisitos do ICE Lite
Esta seção captura brevemente os requisitos do ICE Lite.
Reunião de candidatos
O SBC deve oferecer apenas um candidato. Atualmente, há suporte apenas para candidatos IPV4.
Verificações de conectividade
A implementação do ICE Lite deve responder a todas as verificações de conectividade recebidas. O ponto de extremidade ICE Lite não deve enviar nenhuma conectividade marcar solicitações. (Se as verificações de conectividade forem enviadas em violação, a implementação completa responderá, o que pode resultar na descoberta inesperada de candidatos derivados de pares e potencialmente resultar em falhas de chamada.)
Nomeações
O ponto de extremidade de implementação completo do ICE é o ponto de extremidade Controlador e segue nomeações "regulares" para selecionar os candidatos finais a serem usados para o fluxo de mídia. O ponto de extremidade ICE Lite pode usar as nomeações para concluir o caminho a ser usado para mídia e concluir o estabelecimento de chamadas.
Ao bifurcar com pontos de extremidade par envia 183 respostas provisórias, o SBC deve estar pronto para responder a verificações de vários pontos de extremidade e também nomeações de vários pontos de extremidade se as nomeações acontecerem antes de 200OK. Dependendo da convergência do computador de estado ICE no caminho final e no tempo da resposta do usuário, as nomeações podem acontecer antes ou depois de 200OK. O SBC deve ser capaz de lidar com ambos os casos.
Convergindo para bifurcação
Se a oferta do SBC forks para vários pontos de extremidade do Teams, os pontos de extremidade do Teams poderão responder com uma resposta provisória e iniciar verificações de conectividade. O SBC deve estar preparado para receber verificações de conectividade e responder a verificações de conectividade de vários pontos de extremidade par. Por exemplo, o usuário do Teams pode ser conectado a uma área de trabalho e a um celular. Ambos os dispositivos são notificados da chamada de entrada e tentarão verificações de conectividade com o SBC.
Eventualmente, apenas um dos pontos de extremidade atende à chamada (200OK). Ao receber o 200OK, o SBC pode configurar o contexto certo para processar os pacotes de mídia.
Cenários
Chamada de entrada do SBC
Para esse cenário, há vários pontos de extremidade pares possíveis que o SBC deve manipular:
Os pontos de extremidade do servidor normalmente respondem diretamente com 200OK. Esses pontos de extremidade ICE Full normalmente estão envolvidos em cenários de Caixa postal, fila de chamadas e atendimento automático.
Os pontos de extremidade do cliente podem enviar várias respostas provisórias com marcas diferentes de/para (183) seguidas por um 200OK do ponto de extremidade que atende a chamada. Esses pontos de extremidade ICE Full normalmente representam clientes de usuário final.
Outros pontos de extremidade SBC. Esses pontos de extremidade ICE Lite normalmente estão envolvidos no cenário de tocar simultaneamente pontos de extremidade do cliente e outros números de telefone.
O SBC deve responder a todas as solicitações de conectividade válidas marcar recebidas dos pontos de extremidade ICE Full. Por RFC, os pontos de extremidade ICE Full tornam-se pontos de extremidade controladores. Os pontos de extremidade do Teams (cliente/servidor) executam nomeações "regulares" para concluir verificações de conectividade. O 200Ok final pode ser de um ponto de extremidade que enviou mídia inicial ou de um ponto de extremidade diferente. Ao receber o 200Ok, o SBC deve configurar o contexto certo para o fluxo de mídia.
Mídia inicial
Se houver fluxo de mídia inicial, o SBC deverá se apegar ao primeiro ponto de extremidade que inicia a mídia de streaming; O fluxo de mídia pode começar antes que os candidatos sejam nomeados. O SBC deve ter suporte para enviar DTMF durante essa fase para habilitar cenários de IVR/caixa postal. O SBC deve usar o caminho de maior prioridade no qual recebeu verificações se as nomeações não foram concluídas.
Chamada de saída para SBC
Os pontos de extremidade do Teams são o Chamador para esse cenário e são o ponto de extremidade controlador. Ao receber uma resposta provisória (183) ou uma resposta final(200OK), o ponto de extremidade do Teams inicia verificações de conectividade e segue para nomeações "regulares" para concluir as verificações de conectividade.
Observação: se o SBC enviar uma resposta provisória (183), o SBC deverá estar pronto para receber a conectividade marcar solicitações e potencialmente concluir as nomeações antes de enviar o 200OK. Se as verificações e/ou nomeações forem concluídas antes do recebimento do 200OK, as verificações e/ou nomeações não serão executadas novamente após o recebimento de 200OK. O SBC não deve alterar candidatos do ICE, senha e ufrag (fragmento de nome de usuário) entre 183 e 200.
Para dar suporte à mídia inicial, o SBC pode começar a transmitir a mídia para o candidato ice par, com a maior prioridade com base em verificações de conectividade recebidas, mesmo antes de as nomeações serem concluídas pelo ponto de extremidade do Teams. O SBC deve esperar mídia do Teams em qualquer candidato até que as nomeações sejam concluídas. Depois que um candidato é nomeado, o SBC deve redefinir para o contexto certo para enviar e receber pacotes de mídia.
Manipulação de linhas M no SDP
Em alguns cenários de chamada, outras modalidades de mídia podem ser oferecidas em uma chamada para o PSTN. Por exemplo, m=vídeo se uma chamada de vídeo do Teams for encaminhada para o PSTN. Se o SBC do cliente estiver configurado com bypass de mídia, essas linhas não serão removidas pelo serviço e precisarão ser tratadas pelo SBC a seguir RFC3264: Para cada linha não "m=áudio" na oferta, o SBC deve incluir uma linha "m=" correspondente na resposta e o número da porta nessa linha deve ser definido como zero, rejeitando efetivamente todos os fluxos que não são de áudio.
Requisitos de suporte do SRTP
O SBC deve dar suporte a AES_CM_128_HMAC_SHA1_80 de criptografia SRTP para oferta e resposta no seguinte formato:
"inline:" <key||salt> ["|" lifetime]
A seguir está um exemplo do atributo de criptografia na oferta SDP do SBC:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31
Parâmetros MKI e Length não são necessários.
Para obter mais informações, consulte RFC 4568, seção 6.1.
Requisitos de suporte do SDES
O dispositivo deve ser capaz de oferecer SDES no formato a seguir. Os processadores de mídia da Microsoft sempre preferem o SDES.
Com bypass sem mídia, mesmo que um cliente dê suporte apenas ao DTLS, os Processadores de Mídia serão convertidos em SDES.
Com o bypass de mídia, se um cliente for somente DTLS (estado futuro do Google Chrome), o Roteamento Direto inserirá um MP no caminho, convertendo a chamada de bypass de mídia em bypass não midiúnico. Entre o componente SBC e o processador de mídia do Roteamento Direto, o SDES é sempre usado.
Atualmente, não há nenhum cliente do Teams que ofereça apenas DTLS; no entanto, o Google anunciou que, em algum momento, eles deixarão de dar suporte ao SDES.
Formatar para oferta do SBC no modo de bypass
A oferta deve conter SDES e pode conter DTLS opcional no seguinte formato:
m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux
Formatar para resposta que contém SDES para SBC
m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux
Formatar para oferta do Teams para o SBC
Formatar para SDES oferece apenas ao SBC
m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux