Compartilhar via

Encaminhamento Direto - definições e normas RFC

  • Artigo
  • Aplica-se a:
    Microsoft Teams

Este artigo descreve como o Encaminhamento Direto por Telefone do Teams implementa protocolos padrão RFC. Este artigo destina-se a administradores de voz responsáveis pela configuração da ligação entre o Controlador de Limites de Sessão (SBC) no local e o serviço de proxy SIP (Session Initiation Protocol).

O cliente SBC interfaces com os seguintes componentes no back-end do Microsoft Teams:

  • O proxy SIP para sinalização. Este componente é o componente com acesso à Internet do Encaminhamento Direto que processa as ligações SIP (TLS) entre os SBCs e o Encaminhamento Direto.

  • Os processadores de multimédia para multimédia. Este componente é o componente com acesso à Internet do Encaminhamento Direto que processa o tráfego de multimédia. Este componente utiliza protocolos SRTP e SRTCP.

Para obter mais informações sobre o Encaminhamento Direto, consulte Encaminhamento Direto do Telefone do Teams.

Para obter mais informações sobre como o Encaminhamento Direto implementa o protocolo SIP, veja Direct Routing - Protocolo SIP.

Normas RFC

O Encaminhamento Direto está em conformidade com as normas RFC. O SBC ligado ao Encaminhamento Direto também tem de estar em conformidade com os seguintes RFCs (ou os respetivos sucessores).

Normas aplicáveis a dispositivos que suportam o modo de desativação não multimédia

As seguintes normas aplicam-se a dispositivos que suportam apenas o modo de desativação não multimédia:

  • RFC 3261 SIP: Protocolo de Iniciação de Sessão
  • RFC 3325. Extensão Privada para o Protocolo de Iniciação de Sessão para a identidade afirmada em Redes Fidedignas - Secções sobre o processamento do cabeçalho P-Asserted-Identity. O Encaminhamento Direto envia P-Asserted-Identity com cabeçalhos de ID de Privacidade.
  • RFC 4244 Uma extensão do SIP (Session Initiation Protocol) para as Informações do Histórico necessárias. Veja também: Descrição do Protocolo SIP de Encaminhamento para obter mais informações.
  • RFC 3892 O mecanismo de Referred-By do Protocolo de Iniciação de Sessão
  • RFC 3891 O Cabeçalho "Substitui" do Protocolo de Iniciação de Sessão (SIP)
  • RFC 6337 Utilização do Protocolo SIP (Session Initiation Protocol) do Modelo de Oferta/Resposta. Veja a secção "Desvios de RFC".
  • RFC 3711 e RFC 4771. Proteja o tráfego RTP com SRTP. O SBC tem de conseguir estabelecer chaves com o SDES.
  • RFC 8035 Esclarecimentos de Oferta/Resposta do Protocolo SDP (Session Description Protocol) para RtP/RTCP Multiplexing

Normas aplicáveis a dispositivos que suportam o modo de desativação de multimédia

Além das normas listadas como aplicáveis ao modo não viaduto, são utilizadas as seguintes normas para o modo de desativação do suporte de dados:

Normas aplicáveis ao suporte para transmitir informações de localização aos fornecedores do E911

Desvios dos RFCs

A tabela seguinte lista as secções dos RFC(s) em que a implementação do SIP ou da pilha de multimédia da Microsoft se desvia da norma:

RFC e secções Descrição Desvio
RFC 6337, secção 5.3 Suspensão e Currículo do Suporte de Dados O RFC permite utilizar "a=inactive", "a=sendonly", a=recvonly" para colocar uma chamada em espera. O proxy SIP só suporta "a=inativo" e não compreende se o SBC envia "a=sendonly" ou "a=recvonly".
RFC 6337, secção 5.4 Comportamento ao Receber SDP com c=0.0.0.0 RFC3264 requer que um agente seja capaz de receber o SDP com um endereço de ligação 0.0.0.0, caso em que significa que nem RTP nem RTCP devem ser enviados para o elemento da rede. O proxy SIP não suporta esta opção.
RFC 3261, secção 25 BNF Aumentada para o Protocolo SIP O caráter '#' deve ser enviado como '%23' O proxy SIP envia o caráter "#" num Request-URI unescaped.
RFC 3264, secção 8.3.1 Um Modelo de Oferta/Resposta com SDP A versão 3264 detalha um mecanismo de re-destino de suporte de dados MAY (Opcional) que permite alterar a porta de multimédia, o endereço IP ou o transporte após a sessão ser estabelecida. O destino de multimédia opcional não é suportado. Durante uma chamada, os pedidos SIP para atualizar a porta de multimédia, o endereço IP ou o transporte não são suportados. Os suportes de dados não serão enviados para o destino da sessão atualizado; os suportes de dados do Encaminhamento Direto continuarão a fluir para o destino original.

Nota do RFC que suporta a escolha; O oferecidor tem de estar preparado para receber suportes de dados nas portas antigas e novas assim que a oferta for enviada. O oferenda NÃO deve deixar de ouvir os meios de comunicação no porto antigo até que a resposta seja recebida e os suportes de dados cheguem à nova porta.|

Considerações de transporte TCP/TLS

Ao enviar um pedido SIP (novo ou em diálogo), o Proxy SIP da Microsoft pode abrir uma nova ligação TCP/TLS ou reutilizar uma ligação existente, se existir.

  • Existe um máximo de duas ligações TCP/TLS por FQDN/IP remoto, por cada máquina virtual de proxy SIP. Antes de enviar um pedido SIP, o proxy SIP verifica a existência de ligações TCP ativas com o endereço IP resolvido do SBC/Trunk FQDN de destino. Se existirem duas ligações, serão reutilizadas. Se não existirem duas ligações, é aberta uma nova ligação.

    • Esta lógica é de acordo com a máquina virtual proxy SIP.

    • Os IPs de proxy SIP são servidos por várias máquinas virtuais por região.

    • Na perspetiva do SBC, podem existir várias ligações de proxy de entrada de todas as regiões de proxy SIP.

  • As ligações TCP/TLS abertas pelo proxy SIP não permanecem necessariamente abertas enquanto a chamada o fizer. No entanto, a ligação não fecha imediatamente após uma resposta a um pedido SIP. Se uma ligação não exceder o limite de tempo, poderá ser reutilizada para outros pedidos SIP.

  • O Proxy SIP não suporta o aliasing de ligação, conforme descrito em RFC 5923: Reutilização da Ligação no Protocolo SIP (Session Initiation Protocol).

    • As ligações TCP do proxy SIP de saída apenas suportam pedidos de Proxy SIP de saída (para SBCs) e respostas relacionadas.

    • As ligações TCP de proxy SIP de entrada (a partir de SBCs) apenas suportam pedidos SIP recebidos e respostas relacionadas.

Políticas de tempo limite

  • O tempo limite de inatividade do TCP do proxy SIP é de dois minutos. O temporizador é reposto quando ocorre uma transação SIP através da ligação.

  • O proxy SIP envia a aplicação CRLF keep-alive por RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP).

    • O keep-alive não repõe o temporizador de inatividade TCP.

    • CrLF keep-alive enviado pelo fornecedor SBC repõe o temporizador de inatividade TCP.

  • Devido à restrição de aliasing mencionada anteriormente, o SBC do fornecedor não pode utilizar pedidos SIP em diálogo para repor o temporizador nas ligações criadas pelo Proxy SIP de saída para o SBC do fornecedor.

  • Após dois minutos de idling, (FIN, ACK) é transmitido para o fornecedor SBC pelo Proxy SIP dentro de aproximadamente 10 a 20 segundos.

Observações

  • Recomenda-se que o SBC reutilize ativamente as ligações, como o proxy SIP. Este método poupa tempo, que é necessário para ligações TCP e TLS.

  • O SBC deve renovar a ligação pelo menos uma vez por hora.

  • Quando um novo certificado SBC é carregado, o SBC tem de renovar todas as ligações.

  • Quando as configurações de domínio são atualizadas, recomenda-se que as ligações do SBC sejam renovadas. Caso contrário, será aplicada uma nova configuração após a renovação da cache de proxy SIP interna – até quatro horas.

Modos operacionais

Existem dois modos operacionais para o Encaminhamento Direto:

  • Sem o bypass de multimédia em que todo o tráfego RTP flui entre o cliente do Teams, os processadores de multimédia e o SBC.

  • Com o bypass multimédia em que todos os suportes de dados RTP fluem entre os pontos finais do Teams e o SBC.

O tráfego SIP flui sempre através do proxy SIP.

DTMF

O DTMF na banda não é suportado pela pilha de multimédia.