Vamos considerar um hipotético parceiro Webex 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 entre todos os clientes que gerenciam.

• O parceiro possui sip.telsp.com e pode administrar a infraestrutura DNS e as autoridades de certificação, gerenciar endereços DNS e assinar certificados para este 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 esses dois sites compartilham a conectividade PSTN:

  • Miami

  • Chicago

• A TelSP opera seus gateways locais em nome dos dois clientes CustA e CustB, conforme são referidos a partir deste documento.

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

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

O Webex Calling permite 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 tronco são os seguintes:

A ilustração mostra a associação da localização do cliente ao Gateway e Tronco para CustA :

Nesta implantação, o tronco associado ao local é a conexão PSTN primária desse 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 Configuração do cliente Webex para obter detalhes.

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

A ilustração mostra a associação da localização do cliente ao Gateway e Tronco para CustB :

A ilustração mostra um terceiro local, ou seja, Nova York, que você pode adicionar mais tarde e apontar para o trunk_chicago tronco como sua principal conexão PSTN.

Ao implantar um gateway local que compartilha vários troncos, a Cisco EXIGE usando um FQDN exclusivo por tronco. Consulte Configurar troncos, grupos de rotas e planos de discagem para chamadas Webex para obter detalhes.

Usar um endereço IP e uma porta bem conhecida por tronco é uma escolha ideal. No entanto, a aquisição de 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 estes ponteiros importantes:

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

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

• A Cisco recomenda ter uma porta de escuta exclusiva por tronco pelas seguintes razões:

  1. Fornece isolamento de nível de rede entre os clientes

  2. É típico dos controladores de borda de sessão reutilizar a conexão de soquete TCP efêmera, a menos que haja isolamento fornecido como um locatário exclusivo particionado por um endereço IP ou uma porta de escuta exclusiva para o locatário.

  3. Conexão ou conexões por tronco através do isolamento de locatário fornece melhor rendimento 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 de tronco

Consulte estes exemplos de diferentes modelos para planejamento:

Modelo 1: Endereço IP exclusivo por tronco

Neste modelo, todos os troncos hospedados pelos dois gateways são resolvidos em 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 um formato tabular:

Neste mesmo modelo, o parceiro pode usar um endereço SRV. O Webex Calling permite apenas "_sips._tcp" como a combinação de serviço e protocolo para descobrir o endereço de colega se for um registro SRV.

Uma amostra de como um registro SRV resolve

 nslookup -type=srv_sips._tcp.trunk.miami.custa.sip.telsp.com Servidor:		Endereço 8.8.8.8:	8.8.8.8#53 Resposta não autoritária: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com 

Modelo 2: IP compartilhado em um gateway, mas portas de escuta diferentes

Neste modelo, todos os troncos hospedados no gateway local de Chicago resolvem para o mesmo endereço IP e todos os troncos hospedados no gateway local de Miami resolvem 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.

Neste mesmo modelo, o parceiro está usando um endereço SRV. O Webex Calling permite apenas "_sips._tcp" como a combinação de serviço e protocolo para descobrir o endereço de colega se for um registro SRV.

Uma outra amostra de como um registro SRV resolve é a seguinte. Neste exemplo, existe 1 Um registro por endereço IP. No entanto, a porta é exclusiva por endereço e é representada por meio de uma configuração DNS específica que vincula um endereço SRV à porta direita.

 nslookup -type=srv_sips._tcp.trunk.miami.custa.sip.telsp.com Servidor:		Endereço 8.8.8.8:	8.8.8.8#53 Resposta não autoritária: _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 Servidor:		Endereço 8.8.8.8:	8.8.8.8#53 Resposta não autoritária: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com 

O parceiro possui telsp.com e seus subdomínios. Portanto, o servidor DNS e a autoridade para obter certificados assinados por uma autoridade de certificação aprovada estão com o parceiro.

• O Cisco Webex espera que o parceiro publique o endereço FQDN ou SRV, incluindo Um Registro no domínio público.

• O Cisco Webex espera que o parceiro use uma das autoridades de certificação listadas em, conforme publicado neste document .

Ao usar um FQDN como o endereço do tronco, configure os certificados assinados com o nome comum (CN) ou o número de assunto (SAN) definido como o FQDNs dos troncos.

Use um destes métodos para gerar os FQDNs no certificado:

• Escolha um dos FQDNs como o nome comum (CN) e o resto como número de assunto número alternativo (SAN).

• Coloque o domínio de nível superior (sip.telsp.com) como o CN e todos os FQDNs como SANs.

  No futuro, você poderá validar o certificado com base no domínio de nível superior que essa configuração se apropriar.

Ao usar um SRV como o endereço do tronco, configure certificados assinados com o CN ou SAN para a parte do host do endereço SRV. Um registro ou CNAME ao qual o endereço SRV resolve não é necessário.

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 do Webex Calling

Você pode configurar SBCs aprovados de terceiros, consulte: Introdução ao gateway local

Configure o gateway hospedado pelo parceiro de acordo com estas diretrizes: Introdução ao 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 do Webex Calling

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

No Hub de parceiros, você pode iniciar o Control Hub para CustA ou CustB e configurar o gateway. Use este procedimento para configurar para cada cliente:

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

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

   CustA	Cust B
   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. Este registro permite que o Control Hub verifique se o domínio pertence ao parceiro. Para obter detalhes, consulte Gerenciar seus domínios

   Como O domínio comum é usado para verificação em 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. Como um único domínio é usado em organizações de clientes, qualquer organização não pode reivindicar a propriedade do domínio.
3. Configurar o endereço SBC com FQDN—

   Para o gateway de Miami:

   Parâmetro	CustA	Cust B
   Local	Denver	Boston
   Nome do tronco	trunk_miami	trunk_miami
   Tipo de tronco	Baseado em certificado	Baseado em certificado
   Tipo de dispositivo	por exemplo, Cisco Unified Border Element (ou outro dispositivo compatível)	por exemplo, Cisco Unified Border Element (ou outro dispositivo compatível)
   Tipo de endereço SBC	FQDN	FQDN
   Nome do organizador	tronco.miami.custa	tronco.miami.custb
   Domínio	sip.telsp.com	sip.telsp.com
   Porta	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Número máximo de chamadas simultâneas (250-6500)	500	500

   Para o gateway de Chicago:

   Parâmetro	CustA	Cust B
   Local	Detroit	Dallas
   Nome do tronco	trunk_chicago	trunk_chicago
   Tipo de tronco	Baseado em certificado	Baseado em certificado
   Tipo de dispositivo	por exemplo, Cisco Unified Border Element (ou outro dispositivo compatível)	por exemplo, Cisco Unified Border Element (ou outro dispositivo compatível)
   Tipo de endereço SBC	FQDN	FQDN
   Nome do organizador	tronco.chicago.custa	tronco.chicago.custb
   Domínio	sip.telsp.com	sip.telsp.com
   Porta	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Número máximo de chamadas simultâneas (250-6500)	500	500

   • (Opcional) Não tem um nome exclusivo para o Tronco entre os clientes e o mesmo nome pode ajudar no rastreamento do tronco.

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

4. 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 através de um grupo de rotas.

   • Qualquer plano de discagem pode usar o tronco.

5. Consulte as definições de tronco com os locais associados:

   

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

   

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

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

   

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