Obrigado pelos seus comentários.

Vamos considerar um parceiro Webex hipotético chamado TelSP para ilustrar os diferentes modelos de implantações que o parceiro pode adotar.

Aqui estão as especificações e requisitos de alto nível do TelSP:

• O parceiro planeja usar sip.telsp.com como o domínio de nível superior que é compartilhado por todos os clientes que ele gerencia.

• O parceiro é proprietário do sip.telsp.com e pode administrar a infraestrutura de DNS e as autoridades de certificação, gerenciar endereços DNS e assinar certificados para esse domínio e seus subdomínios.

• O parceiro pode implantar dois controladores de borda de sessão distintos (físicos ou virtuais) como gateways locais para acesso PSTN compartilhado entre os clientes finais.

• O parceiro tem dois sites físicos, e ambos compartilham conectividade PSTN:

  • Miami

  • Chicago

• A TelSP opera seus gateways locais em nome dos dois clientes CuSTA e CuStb, conforme referidos a partir deste documento.

O cenário desejado é ter originação/rescisão de PSTN para ambos os clientes que usam os gateways de Miami e Chicago fornecidos pelo parceiro, conforme mostrado na ilustração:

Exemplo de implantação simplificada

O exemplo simplificado a seguir demonstra como a identidade Peer cert permite que um único certificado ofereça suporte a vários troncos de clientes:

• Certificado — sip.telsp.com

• Troncos

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identidade do certificado de pares — sip.telsp.com

• Resultado

  • Certificado único é usado

  • Vários troncos de clientes são suportados

Associando a localização do cliente ao tronco e ao gateway

As seções a seguir fornecem mapeamentos de configuração detalhados para a implantação descrita acima.

Webex Callingpermite a criação de troncos e o compartilhamento de um tronco em vários locais. Ao criar o tronco, associe o tronco a um local.

Para CuSTA, os detalhes do porta-malas são os seguintes:

A ilustração mostra a associação da localização do cliente ao Gateway and Trunk for CuSTA:

Nessa implantação, o tronco associado ao local é a conexão PSTN primária para esse local. O outro tronco é usado como uma conexão PSTN secundária ou rota para entradas específicas do plano de discagem. A implementação da relação de conexão PSTN primária e secundária é por meio de um conceito de grupo de rotas. Consulte a seção Configurar troncos de gateway na seção Control Hub para obter detalhes.

Para CustB, uma configuração semelhante com os seguintes troncos é criada:

A ilustração mostra a associação da localização do cliente ao Gateway and Trunk for CuStb:

A ilustração mostra um terceiro local, a saber, Nova York, que você pode adicionar posteriormente e apontar para o tronco trunk_chicago como sua conexão PSTN primária .

Ao implantar um gateway local que compartilha vários troncos, a Cisco exige o uso de um FQDN exclusivo por tronco. Consulte Configure-trunks, -route-groups, -and-dial-plans-for-webex-calling para obter detalhes.

Usar um endereço IP e uma porta conhecida por tronco é a escolha ideal. No entanto, adquirir um endereço IPv4 público pode ser um desafio para alguns parceiros que desejam usar um endereço por gateway por site.

Portanto, leia estas dicas importantes:

• A Cisco não exige um endereço IP por tronco.

• Um endereço de tronco pode ser resolvido para um endereço IP exclusivo ou para o endereço compartilhado entre outro tronco.

• A Cisco recomenda configurar cada conexão de tronco com uma combinação exclusiva de endereço IP e porta no gateway local pelos seguintes motivos:

  1. A manutenção de links de conexão TCP separados por tronco suporta a capacidade máxima de chamadas simultâneas por tronco. Compartilhar combinações de endereços IP e portas entre troncos pode afetar negativamente a capacidade de chamadas.

  2. Fornece isolamento em nível de rede entre os clientes

  3. É comum que os controladores de borda de sessão reutilizem a conexão efêmera de soquete TCP, a menos que haja isolamento fornecido como um inquilino exclusivo particionado por um endereço IP ou uma porta de escuta exclusiva para o inquilino.

  4. A conexão ou conexões por tronco por meio do isolamento do locatário fornecem melhor taxa de transferência, especificamente em condições de rede com alta perda de dados. Portanto, o tráfego de um cliente não afeta o outro.

Endereço IP por gateway: configuração e recomendações do tronco

Consulte estes exemplos de diferentes modelos de planejamento:

Modelo 1: endereço IP exclusivo por tronco

Nesse modelo, todos os troncos hospedados por ambos os gateways são resolvidos para um endereço IP exclusivo e cada um desses troncos pode ou não usar a mesma porta, mas, idealmente, a mesma porta.

Representando as informações em formato tabular:

Nesse mesmo modelo, o parceiro pode usar um endereço SRV. Webex Callingsó permite “_sips. _tcp” como a combinação de serviço e protocolo para descobrir o endereço do peer se for um registro SRV.

Uma amostra de como um registro SRV resolve

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Modelo 2: IP compartilhado por gateway, portas de escuta exclusivas

Nesse modelo, todos os troncos hospedados no gateway local de Chicago são resolvidos para o mesmo endereço IP e todos os troncos hospedados no gateway local de Miami são resolvidos para um IP diferente. No entanto, ao usar o mesmo IP, cada tronco é configurado usando um FQDN no hub de controle e é configurado com uma porta exclusiva.

Nesse mesmo modelo, o parceiro está usando um endereço SRV. Webex Callingsó permite “_sips. _tcp” como a combinação de serviço e protocolo para descobrir o endereço do peer se for um registro SRV.

Outro exemplo de como um registro SRV é resolvido é o seguinte. Neste exemplo, existe 1 registro A por endereço IP. No entanto, a porta é exclusiva por endereço e é representada por meio de uma configuração de DNS específica que vincula um endereço SRV à porta correta.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

Para troncos baseados em SRV, a identidade do certificado Peer é inicialmente preenchida a partir dos valores SRV configurados e pode ser personalizada, sujeita às mesmas regras de validação.

O parceiro possui telsp.com e seus subdomínios. Portanto, o servidor DNS e a autoridade para obter certificados assinados por uma autoridade certificadora aprovada são do parceiro.

• Cisco Webexespera que o parceiro publique o endereço FQDN ou SRV, incluindo registros A, no domínio público.

• Cisco Webexespera que o parceiro use uma das autoridades de certificação listadas neste documento.

Ao configurar troncos usando FQDN ou SRV:

• Cada tronco ainda deve ter um FQDN exclusivo para roteamento e identificação

• Os registros DNS (registro A ou SRV) devem ser configurados corretamente e resolvíveis

• Esses FQDNs são usados para sinalização e roteamento. A validação do certificado é realizada com base na identidade de certificado Peer configurada, que usa como padrão os valores do FQDN do tronco, mas pode ser personalizada para uma identidade compartilhada de propriedade do parceiro.

  O campo Peer cert identity é preenchido previamente a partir do FQDN do tronco e pode ser substituído por um domínio compartilhado de propriedade do parceiro para usar um único certificado em vários troncos de clientes.

Configurar o Gateway

Use esses recursos para configurar um gateway local.

Para configurar o Cisco CUBE, use este procedimento: Configurar o gateway local no Cisco IOS XE para Webex Calling

Você pode configurar SBCs de terceiros aprovados, consulte: Comece a usar o Local Gateway

Configure o gateway hospedado pelo parceiro de acordo com estas diretrizes: Comece a usar o gateway local

Defina cada tronco de acordo com as instruções relevantes para o dispositivo SBC. Para obter as instruções do Cisco CUBE, consulte: Configurar o gateway local no Cisco IOS XE para Webex Calling

Configure classes de voz, pares de discagem e grupos de pares de discagem para tráfego de entrada e saída do tronco conforme a imagem:

Ao provisionar um tronco, o Control Hub fornece uma opção para configurar a identidade do certificado Peer na página Adicionar tronco. Esse aprimoramento simplifica o fluxo de trabalho ao permitir que os parceiros configurem e reutilizem um único domínio de alto nível em várias organizações de clientes. Essa abordagem elimina a necessidade de certificados separados por cliente ou tronco, reduzindo o esforço operacional e simplificando o processo de configuração.

Ao configurar troncos no Control Hub, defina uma identidade de certificado Peer para permitir o uso de um único certificado para seu domínio de nível superior em todas as organizações do cliente. Certifique-se de que o CN ou SAN do certificado inclua esse domínio de nível superior. Com a identidade Peer cert, o gateway local usa um único certificado cujo CN ou SAN contém o domínio compartilhado do parceiro (por exemplo, sip.telsp.com). Não há suporte para certificados curinga (por exemplo, *.sip.telsp.com). Webex Callingaceita esse certificado para cada tronco de cliente configurado explicitamente com esse valor como sua identidade de certificado Peer. O certificado deve conter o valor exato da identidade do certificado Peer configurado em seu CN ou SAN. Isso elimina a necessidade de configurar certificados separados ou entradas CN/SAN para FQDNs de tronco individuais.

Verificação de domínio e uso de certificados

É importante entender como a verificação de domínio difere do uso do certificado:

• Verificação de domínio (por cliente) — Cada organização do cliente deve verificar o domínio de forma independente (por exemplo, sip.telsp.com) adicionando um registro TXT exclusivo no DNS. Isso garante que o parceiro seja o proprietário do domínio e evita o uso não autorizado.

• Gerenciamento de certificados (global) — Um único certificado emitido para o domínio de nível superior do parceiro pode ser compartilhado em todos os troncos de clientes usando a identidade Peer Cert. Não há necessidade de manter certificados separados por cliente ou por tronco.

Comportamento de identidade do certificado de pares

A identidade de certificado de pares define a identidade que se Webex Calling espera no certificado apresentado pelo gateway local.

Quando configurado:

• Webex Callingvalida o certificado comparando a identidade do certificado Peer configurada com o CN ou SAN no certificado

• Se os valores corresponderem, a conexão TLS será aceita

• Se os valores não corresponderem, a conexão será rejeitada

Somente troncos explicitamente configurados com a identidade de certificado Peer correspondente podem ser autenticados.

A validação do certificado por si só não é a única verificação realizada durante a autenticação. Além de validar o certificado CN ou SAN em relação à identidade de certificado Peer configurada, Webex Calling também verifica se o FQDN do tronco está explicitamente configurado e associado à identidade de certificado Peer correspondente no Control Hub.

A identidade do certificado Peer é pré-preenchida a partir dos valores FQDN/SRV do tronco. Se você mantiver os padrões, o comportamento existente do certificado por tronco permanecerá inalterado. Os troncos existentes baseados em certificados continuam funcionando sem modificações. Você pode adotar uma identidade de certificado Peer compartilhada em troncos novos ou existentes no seu próprio ritmo, e os dois modelos podem coexistir.

1. Exemplo de configuração válido:

   • Certificado CN — sip.telsp.com

   • Certificado SAN — custa.sip.telsp.com

   • Identidade do certificado de pares — custa.sip.telsp.com

   • FQDN do tronco — trunk.miami.custa.sip.telsp.com

   Resultado — A conexão é bem-sucedida porque a identidade do certificado Peer (custa.sip.telsp.com) corresponde ao valor SAN no certificado e o FQDN do tronco (trunk.miami.custa.sip.telsp.com) é um subdomínio da identidade configurada do certificado Peer.

2. Exemplo de falha de conexão:

   • Certificado CN — sip.telsp.com

   • Certificado SAN — custa.sip.telsp.com

   • Identidade do certificado de pares — custb.sip.telsp.com

   • FQDN do tronco — trunk.miami.custb.sip.telsp.com

   Resultado — A conexão falha no handshake TLS porque a identidade do certificado Peer (custb.sip.telsp.com) não está presente no CN ou SAN do certificado. O FQDN do tronco é corretamente um subdomínio da identidade do certificado Peer, mas o certificado não carrega essa identidade.

3. Exemplo de configuração inválida:

   • Certificado CN — sip.telsp.com

   • Certificado SAN — custa.sip.telsp.com

   • Identidade do certificado de pares — custa.sip.telsp.com

   • FQDN do tronco — trunk.miami.custb.sip.telsp.com

   Resultado — O Control Hub rejeita essa configuração economizando tempo porque o FQDN do tronco (trunk.miami.custb.sip.telsp.com) não é igual ou não é um subdomínio da identidade de certificado Peer configurada (custa.sip.telsp.com).

No Partner Hub, você pode iniciar o Control Hub para CuSTA ou CuStb e configurar o gateway. Use este procedimento para configurar para cada cliente:

1. Crie o tronco — Adicione um tronco em Roteamento de chamadas/tronco de chamadas/tronco para cada gateway compartilhado de parceiro. Para configurar um tronco, consulte Configurar troncos, grupos de rotas e planos de discagem para Webex Calling

2. Adicione um domínio e verifique—Adicione e verifique o seguinte domínio que é usado para criar um tronco em Configurações de gerenciamento/organização/domínios.

   Cliente B	Cliente C
   sip.telsp.com	sip.telsp.com

   Ao adicionar um domínio, um token é gerado e colocado no registro TXT do domínio no servidor DNS do parceiro. Esse registro permite que o Control Hub verifique se o domínio é de propriedade do parceiro. Para obter detalhes, consulte Gerenciar seus domínios

   O domínio comum é usado para verificação de cada cliente. No entanto, como essa verificação ocorre no nível da organização do cliente, certifique-se de que um token diferente seja gerado e usado para verificação em cada organização do cliente. Porque um único domínio é usado em todas as organizações do cliente, e cada organização do cliente deve verificar o domínio de forma independente usando um registro TXT exclusivo, mesmo quando compartilha o mesmo domínio.

   Somente a verificação do domínio é necessária para a identidade do certificado Peer. Não reivindique o domínio compartilhado em uma organização do cliente. Um domínio só pode ser reivindicado por uma organização, enquanto o mesmo domínio pode ser verificado em várias organizações.

3. Configurar endereço SBC com FQDN—

   Para o gateway de Miami:

   Parâmetro	Cliente B	Cliente C
   Localização	Denver	Boston
   Nome do tronco	trunk_miami	trunk_miami
   Tipo de tronco	Baseado em certificado	Baseado em certificado
   Tipo de dispositivo	ex. Cisco Unified Border Element(ou outro dispositivo compatível)	ex. Cisco Unified Border Element(ou outro dispositivo compatível)
   Tipo de endereço SBC	FQDN	FQDN
   Nome do host	lgw.miami	lgw.miami
   Domínio	sip.telsp.com	sip.telsp.com
   Porto	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Número máximo de chamadas simultâneas (250-6500)	500	500

   Para o gateway de Chicago:

   Parâmetro	Cliente B	Cliente C
   Localização	Detroit	Dallas
   Nome do tronco	trunk_chicago	trunk_chicago
   Tipo de tronco	Baseado em certificado	Baseado em certificado
   Tipo de dispositivo	ex. Cisco Unified Border Element(ou outro dispositivo compatível)	ex. Cisco Unified Border Element(ou outro dispositivo compatível)
   Tipo de endereço SBC	FQDN	FQDN
   Nome do host	lgw.chicago	lgw.chicago
   Domínio	sip.telsp.com	sip.telsp.com
   Porto	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Número máximo de chamadas simultâneas (250-6500)	500	500

   • (Opcional) Os nomes dos troncos não precisam ser exclusivos em todas as organizações do cliente. Reutilizar o mesmo nome (por exemplo, trunk_miami) facilita o rastreamento do tronco.

   • Alguns SBCs permitem configurar a mesma porta, mas essa configuração pode afetar a capacidade. Portanto, use portas diferentes.

4. Identidade do certificado de pares—

   • Prefixo — O prefixo é opcional. Deixe-o vazio para definir a identidade do certificado Peer apenas para o domínio. Esse é o modelo de certificado compartilhado usado neste artigo (identidade de certificado por pares — sip.telsp.com, abrangendo todos os troncos de clientes). Opcionalmente, insira um prefixo para definir uma identidade de certificado mais específica (por exemplo, prefixo: CustomerB, Domínio: customerb.sip.telsp.com para um certificado por cliente). O próprio FQDN do tronco permanece definido pelos campos SBC, nome do host e domínio e deve ser igual ou um subdomínio da identidade resultante do certificado Peer.

     Exemplo:

     Prefixo — cliente B

     Domínio — sip.telsp.com

     Resultado — customerb.sip.telsp.com

   • Domínio: selecione um domínio na lista de domínios verificados na organização do cliente. A identidade do certificado Peer resultante (prefixo + domínio) deve corresponder ao CN ou SAN do certificado que seu SBC apresenta. Webex Callingusa esse valor para autenticar a conexão TLS.

     

     O Control Hub rejeita essa configuração economizando tempo porque o FQDN do tronco não está sob a identidade configurada do certificado Peer.

     Se a identidade do certificado Peer não corresponder ao CN ou SAN no certificado apresentado pelo SBC, Webex Calling rejeitará a conexão TLS e o tronco não conseguirá se estabelecer.

5. Usando troncos — Escolha qualquer local arbitrário para o tronco, devido ao seguinte:

   • Qualquer local pode usar o tronco em uma conexão PSTN.

   • Você pode acessar o tronco por meio de um grupo de rotas.

   • Qualquer plano de discagem pode usar o porta-malas.

6. Veja as definições de tronco com os locais associados:

   

   Você pode usar esses troncos para criar grupos de rotas. Na imagem, um grupo de rotas rg_miami_chicago é definido, que roteia chamadas para o tronco trunk_miami como a opção primária e para o tronco trunk_chicago como uma opção secundária.

   

   Você pode definir um segundo grupo de rotas rg_chicago_miami que roteia chamadas para o tronco trunk_chicago como a opção principal e para o tronco trunk_miami como uma opção secundária.

7. Os troncos e grupos de rotas definidos agora estão disponíveis na opção Calling Connection PSTN para cada local. Na imagem, veja a localização de Denver.

   

8. Você pode usar os troncos e os grupos de rotas na definição do plano de discagem. Por exemplo, um intervalo de números local em Chicago para o cliente é dividido para terminar no grupo de rotas rg_chicago_miami (para todos os locais) na imagem:

   

   

Provisione em grande escala com APIs

Os parceiros que gerenciam um grande número de organizações de clientes podem provisionar domínios em grande escala usando APIs em vez da interface do usuário.

• Verificar domínio

• Roteamento de chamadas