Problemas de conectividade SBC
Ao configurar o Roteamento Direto, você poderá experimentar os seguintes problemas de conectividade do SBC (Controlador de Borda de Sessão):
- As opções SIP (Protocolo de Iniciação de Sessão) não são recebidas.
- Ocorrem problemas de conexões TLS (Transport Layer Security).
- O SBC não responde.
- O SBC é marcado como inativo no centro de administração do Microsoft Teams.
Esses problemas provavelmente são causados por ambas as seguintes condições:
- Um certificado TLS enfrenta problemas.
- Um SBC não está configurado corretamente para Roteamento Direto.
Este artigo lista alguns problemas comuns relacionados a opções SIP e certificados TLS e fornece resoluções que você pode experimentar.
Visão geral do processo de opções SIP
O SBC envia uma solicitação de conexão TLS que inclui um certificado TLS para o FQDN (nome de domínio totalmente qualificado) do servidor proxy SIP (por exemplo, sip.pstnhub.microsoft.com).
O proxy SIP verifica a solicitação de conexão.
- Se a solicitação não for válida, a conexão TLS será fechada e o proxy SIP não receberá opções SIP do SBC.
- Se a solicitação for válida, a conexão TLS será estabelecida e o SBC a usará para enviar opções SIP para o proxy SIP.
Depois de receber opções SIP, o proxy SIP verifica o Record-Route para determinar se o SBC FQDN pertence a um locatário conhecido. Se as informações do FQDN não forem detectadas lá, o proxy SIP verificará o cabeçalho Contato.
Se o SBC FQDN for detectado e reconhecido, o proxy SIP enviará uma mensagem 200 OK usando a mesma conexão TLS.
O proxy SIP envia opções SIP para o SBC FQDN listado no cabeçalho Contato das opções SIP recebidas do SBC.
Depois de receber opções SIP do proxy SIP, o SBC responde enviando uma mensagem 200 OK . Esta etapa confirma que o SBC está íntegro.
Como etapa final, o SBC é marcado como Ativo no centro de administração do Microsoft Teams.
Observação
Em um modelo hospedado, as opções SIP devem ser enviadas apenas do SBC hospedado. O status de SBCs que estão em um modelo de tronco derivado baseia-se no SBC main.
Problemas de opções SIP
Depois que a conexão TLS for estabelecida com êxito, e o SBC for capaz de enviar e receber mensagens de e para o proxy SIP do Teams, ainda pode haver problemas que afetam o formato ou o conteúdo das opções SIP.
O SBC não recebe uma resposta "200 OK" do proxy SIP
Essa situação poderá ocorrer se você estiver usando uma versão mais antiga do TLS. Para impor uma segurança mais rigorosa, habilite o TLS 1.2.
Verifique se o certificado SBC não está autoassinado e se você o recebeu de uma AUTORIDADE de Certificado confiável (AC).
Se você estiver usando a versão mínima necessária do TLS ou superior, e seu certificado SBC for válido, o problema poderá ocorrer porque o FQDN está configurado incorretamente em seu perfil SIP e não é reconhecido como pertencente a qualquer locatário. Verifique as seguintes condições e corrija os erros encontrados:
- O FQDN fornecido pelo SBC no cabeçalho Record-Route ou Contato é diferente do que está configurado no Teams.
- O cabeçalho Contato contém um endereço IP em vez do FQDN.
- O domínio não está totalmente validado. Se você adicionar um FQDN que não foi validado anteriormente, você deverá validá-lo agora.
- Depois de registrar um nome de domínio SBC, você deve ativá-lo adicionando pelo menos um usuário licenciado por E3 ou E5.
SBC recebe resposta "200 OK", mas não opções SIP
O SBC recebe a resposta 200 OK do proxy SIP, mas não as opções SIP enviadas do proxy SIP. Se esse erro ocorrer, certifique-se de que o FQDN listado no cabeçalho Record-Route ou Contato esteja correto e resolva para o endereço IP correto.
Outra causa possível para esse problema pode ser regras de firewall que estão impedindo o tráfego de entrada. Verifique se as regras de firewall estão configuradas para permitir conexões de entrada de todos os endereços IP de sinalização de proxy SIP.
O SBC status está intermitentemente inativo
Esse problema pode ocorrer nas seguintes situações:
O SBC está configurado para enviar opções SIP não para FQDNs, mas para os endereços IP específicos aos quais eles resolve. Durante a manutenção ou interrupções, esses endereços IP podem ser alterados para um datacenter diferente. Portanto, o SBC enviará opções SIP para um datacenter inativo ou sem resposta. Faça o seguinte:
Verifique se o SBC é detectável e configurado para enviar opções SIP apenas para FQDNs.
Verifique se todos os dispositivos na rota, como SBCs e firewalls, estão configurados para permitir a comunicação de e para todos os FQDNs de sinalização da Microsoft.
Para fornecer uma opção de failover quando a conexão de um SBC é feita a um datacenter que está enfrentando um problema, o SBC deve ser configurado para usar todos os três FQDNs proxy SIP:
- sip.pstnhub.microsoft.com
- sip2.pstnhub.microsoft.com
- sip3.pstnhub.microsoft.com
Observação
Dispositivos com suporte a nomes DNS podem usar sip-all.pstnhub.microsoft.com para resolve a todos os endereços IP possíveis.
Para obter mais informações, confira Sinalização SIP: FQDNS.
O certificado raiz ou intermediário instalado não faz parte do emissor da cadeia de certificados SBC. Quando o SBC iniciar o aperto de mão de três vias durante o processo de autenticação, o serviço teams não poderá validar a cadeia de certificados no SBC e redefinirá a conexão. O SBC pode ser capaz de se autenticar novamente assim que o certificado Raiz público for carregado novamente no cache de serviço ou a cadeia de certificados for fixada no SBC. Verifique se o certificado intermediário e raiz instalado no SBC está correto.
Para obter mais informações sobre certificados, consulte Certificado confiável público para o SBC.
O FQDN não corresponde ao conteúdo de CN ou SAN no certificado fornecido
Esse problema ocorrerá se um curinga não corresponder a um subdomínio de nível inferior. Por exemplo, o curinga \*\.contoso.com corresponderia sbc1.contoso.com, mas não customer10.sbc1.contoso.com. Você não pode ter vários níveis de subdomínios em um curinga. Se o FQDN não corresponder ao NOME Comum (CN) ou nome alternativo da entidade (SAN) no certificado fornecido, solicite um novo certificado que corresponda aos nomes de domínio.
Para obter mais informações sobre certificados, consulte o certificado público confiável para a seção SBC do Roteamento Direto do Plano.
A ativação de domínio não está registrada no ambiente do Microsoft 365
Para ativar totalmente um domínio para um locatário e distribuí-lo no ambiente do Microsoft 365, você deve atribuir pelo menos um usuário licenciado ao subdomínio usado pelo SBC. Quando todos os requisitos forem atendidos, pode levar até 24 horas para que o domínio seja ativado.
Para obter uma lista das licenças necessárias para o Roteamento Direto, consulte a seção "Licenciamento e outros requisitos" do Roteamento Direto do Plano.
Para obter mais informações sobre esse processo, consulte a seção Conectar o SBC ao locatário do SBC (Controlador de Borda de Sessão) ao Roteamento Direto.
Problemas de conexão TLS
Se a conexão TLS for fechada imediatamente e as opções SIP não forem recebidas do SBC ou se 200 OK não for recebido do SBC, o problema poderá ser com a versão TLS. A versão TLS configurada no SBC deve ser 1.2 ou superior.
O certificado SBC é autoassinado ou não de uma AC confiável
Se o certificado SBC for autoassinado, ele não será válido. Verifique se o certificado SBC é obtido de uma AUTORIDADE de Certificado confiável (AC). O certificado deve conter pelo menos um FQDN que pertence a um locatário do Microsoft 365.
Para obter uma lista de CAs com suporte, consulte o certificado de confiança pública para a seção SBC do Roteamento Direto do Plano.
O SBC não confia no certificado proxy SIP
Se o SBC não confiar no certificado proxy SIP, baixe e instale o certificado raiz do Baltimore CyberTrust no SBC. Para baixar o certificado, confira Cadeias de criptografia do Microsoft 365.
Para obter uma lista de CAs com suporte, consulte o certificado de confiança pública para a seção SBC do Roteamento Direto do Plano.
O certificado SBC é inválido
Se o Painel de Integridade para Roteamento Direto no centro de administração do Microsoft Teams indicar que o certificado SBC expirou ou revogou, solicite ou renove o certificado de uma AUTORIDADE de Certificado confiável (AC). Em seguida, instale-o no SBC. Para obter uma lista de CAs com suporte, consulte o certificado de confiança pública para a seção SBC do Roteamento Direto do Plano.
Ao renovar o certificado SBC, você deve remover as conexões TLS estabelecidas do SBC para a Microsoft com o certificado antigo e reinstituí-las com o novo certificado. Isso garantirá que os avisos de expiração de certificado não sejam disparados no centro de administração do Microsoft Teams. Para remover as conexões TLS antigas, reinicie o SBC durante um período de tempo que tenha tráfego baixo, como uma janela de manutenção. Se você não puder reiniciar o SBC, entre em contato com o fornecedor para obter instruções para forçar o fechamento de todas as conexões TLS antigas.
Certificado SBC ou certificados intermediários estão ausentes na mensagem "Olá" do SBC TLS
Verifique se um certificado SBC válido e todos os certificados intermediários necessários estão instalados corretamente e se as configurações de conexão TLS no SBC estão corretas.
Às vezes, mesmo que tudo pareça correto, um exame mais aprofundado da captura de pacotes pode revelar que o certificado TLS não é fornecido à infraestrutura do Teams.
A conexão SBC é interrompida
A conexão TLS é interrompida ou não é configurada, embora os certificados e as configurações do SBC não tenham problemas.
A conexão TLS pode ter sido fechada por um dos dispositivos intermediários (como um firewall ou um roteador) no caminho entre o SBC e a rede microsoft. Verifique se há problemas de conexão na rede gerenciada e corrija-os.
Mais informações
Ainda precisa de ajuda? Acesse a Microsoft Community.