Obrigado pelos seus comentários.

Webex CallingBorda

Para realizar um registro ou chamada SIP, conclua estas etapas:

• Descubra o endereço do host de um endpoint SIP para nós ativos do Edge.

• Preencha todas as condições prévias relacionadas à configuração do usuário e do dispositivo.

• Certifique-se de que o endpoint tenha conectividade de rede pública para iniciar a descoberta do serviço.

• Preencha as condições prévias para inicializar o endpoint com uma configuração de provisionamento específica da região ou do datacenter. Essa configuração ajuda a obter o sufixo do nome de domínio relevante para a descoberta do serviço.

IPv4 versus IPv6

Os dispositivos podem operar em uma versão única ou no modo de pilha dupla. É a configuração que determina as mudanças no protocolo preferido e essas mudanças não fazem parte da descoberta do serviço.

• Modo de pilha única — ativa somente um protocolo IP (por exemplo, IPv4) e ignora os outros endereços de protocolo.

• Modo de pilha dupla — seleciona uma versão IP preferida por meio da configuração.

O cliente considera que a prioridade de todos os endereços preferenciais é menor (ou seja, preferencial) do que todos os endereços do IP. Se o IPv4 for preferido, todos os endereços IPv4 serão tentados antes de tentar um endereço IPv6. Se todos os endereços falharem, o ciclo recomeça com o endereço de protocolo preferencial de menor prioridade.

Um cliente móvel que se registra após o recebimento de uma notificação push pode decidir otimizar o modo com base em registros anteriores.

Resolução do endereço do host a partir do DNS SRV endereço

No arquivo de configuração do endpoint obtido com o provisionamento, o indicador de domínio especifica o nome de domínio para descobrir o serviço de borda de acesso. Um exemplo do nome de domínio é:

wxc.edge.bcld.webex.com

A partir do exemplo, o endpoint que executa uma DNS SRV pesquisa para esse domínio pode gerar uma resposta semelhante à seguinte:

# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

Nesse caso, o registro SRV aponta para registros de 3 A.

sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

No exemplo, é anunciado que todos os hosts entrem em contato com a porta 5061 com peso e prioridade diferentes.

Considere esses requisitos para endpoints.

• Um endpoint deve usar _sips._tcp(combinação de serviço e protocolo) como prefixo para realizar uma DNS SRV pesquisa para obter o endereço do host para iniciar a comunicação baseada em TLS.

• Um endpoint deve DNS SRV pesquisar as condições explicadas na seção Resolução do endereço do host na seção de DNS SRV endereço.

• Um endpoint deve respeitar o host, a porta, o peso e a prioridade conforme anunciado para cada endereço do host. Além disso, ele deve criar uma afinidade de host para porta ao criar uma conexão de soquete durante o registro SIP.

• Especificamente para o uso do DNS SRV registro, os critérios de seleção de anfitriões com base na prioridade e no peso são explicados na RFC 2782.

Requisitos para SIP seguro com mTLS (TLS mútuo)

Os requisitos são explicados em detalhes aqui.

É necessário um certificado assinado para uma autorização e autenticação bem-sucedidas de chamadas do tronco. O certificado deve atender aos seguintes requisitos:

• O certificado deve ser assinado por uma CA mencionada em Quais autoridades de certificação raiz são suportadas para chamadas para plataformas Cisco Webex de áudio e vídeo?

• Faça o upload do pacote de confiança mencionado em Quais autoridades certificadoras raiz são suportadas para chamadas para plataformas Cisco Webex de áudio e vídeo? para o CUBE.

• O certificado deve ser válido sempre:

  • Os certificados assinados devem sempre ter uma validade válida.

  • Os certificados raiz ou intermediários devem ter uma expiração válida e não devem ser revogados.

  • Certificados contendo somente o uso estendido de chave (EKU) do Server Authentication são suportados. Webex Callingnão valida nem impõe a presença do EKU de autenticação de cliente durante o estabelecimento do handshake TLS.

    Alguns controladores de borda de sessão (SBC) de terceiros podem impor uma validação estrita do EKU e podem rejeitar certificados que não incluem o EKU de autenticação do cliente. Nesses casos, certifique-se de que o SBC esteja configurado para aceitar certificados somente com EKU de Autenticação de Servidor ou para desativar a validação estrita de EKU (se houver suporte).

  • Os certificados devem conter o Nome de Domínio Totalmente Qualificado (FQDN) como nome comum ou nome alternativo do assunto no certificado com o FQDN escolhido no Control Hub. Por exemplo:

    • Um tronco configurado no Control Hub da sua organização com london.lgw.cisco.com:5061 como FQDN deve conter london.lgw.cisco.com no certificado CN ou SAN.

    • Um tronco configurado a partir do Control Hub da sua organização com london.lgw.cisco.com era o SRV que deveria conter london.lgw.cisco.com no certificado CN ou SAN. Os registros para os quais o endereço SRV é resolvido (registro CNAME/A/endereço IP) são opcionais na SAN.

  • Você pode compartilhar certificados com mais de um gateway local, no entanto, certifique-se de que os requisitos de FQDN sejam atendidos.

Fora do escopo

Este artigo não inclui as seguintes informações relacionadas à segurança de rede:

• Requisitos F5 para CA e Ciphers

• Uma API baseada em HTTP para baixar regras de firewall para Webex.

• API para um pacote de confiança

• Requisito de firewall e desativação do ALG