Voz e comunicações unificadas : Cisco Unified Communications Manager (CallManager)

Distribuição de Casos Práticos de telefonia IP: Boletim nacional de cingapura

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento faz disponível ao cliente Cisco, aos Parceiros, e aos empregados as experiências e as lições instruídas do desenvolvimento da Telefonia IP no National Bulletin (NB) em Singapura. Este documento tenta:

  • Descreva e critique o projeto da solução distribuída.

  • Identifique melhorias possíveis ao projeto.

  • Destaque trocas no projeto.

O NB é uma empresa de publicidade global. A operação Cingapura consiste em aproximadamente 6,000 vendas, em impressão, e em pessoal da escrita. O pessoal NB reside em um número de prédios do escritório situados dentro da mesma vizinhança. Em finais de 2000, o NB adicionou uma outra construção, os DB que constroem, a seu terreno. Esta construção adicional abriga 750 empregados. Um pouco do que distribui um central telefônica privada (PBX) na construção nova, NB decidido distribuir uma solução de telefonia do IP. Como tal, o desenvolvimento de campo inclui o componente de rede.

A solução de telefonia do IP NB é um projeto do único-local. Todos os usuários da Telefonia IP são ficados situados nos DB que constroem, e distribuídos através de cinco assoalhos. Os gateways dos CallManagers, da rede telefônica pública comutada de Cisco (PSTN), e o correio de voz são ficados igualmente fisicamente na construção DB.

Um link do Wide Area Network (WAN) conecta os DB que constroem à construção nbap menos de 1 quilômetro afastado. Este link MACILENTO leva o tráfego do protocolo voice over internet (VoIP) transversalmente ao NBAP, onde um gateway conecta no NB PBX a rede mundial. Este diagrama mostra os DB e as construções nbap.

/image/gif/paws/13968/65363.gif

Infra-estrutura de LAN de campus

O infra-estruturo de LAN DB consiste em um Catalyst 6509 Switch no núcleo e em nove Catalyst 4006 Switch nos armários de fiação. Esta tabela mostra como o Catalyst 6509 Switch é povoado.

-
Slot Módulo Descrição
1 WS-X6K-SUP1A-MSFC Supervisor com Multilayer Switch Feature Card (MSFC)
2 WS-X6K-S1A-MSFC2/2 Supervisor com MSFC
3 WS-X6416-GBIC módulo 16-port GE
4 WS-X6408A-GBIC módulo 8-port GE
5 WS-X6348-RJ45V módulo 48-port 10/100 com potência em linha
6 WS-X6608-E1 gateway 8-port E1
7 WS-X6624-FXS gateway da estação de câmbio internacional (FXO) 24-port
8 WS-X6624-FXS gateway FXS 24-port
9 Vazio

Esta tabela mostra como os Catalyst 4006 Switch são povoados.

Slot Módulo Descrição
1 WS-X4013 Supervisor 2 com duas portas do gigabit Ethernet
2 WS-X4148-RJ45V módulo 48-port 10/100 com potência em linha
3 WS-X4148-RJ45V módulo 48-port 10/100 com potência em linha
4 WS-X4148-RJ45V módulo 48-port 10/100 com potência em linha
5 WS-X4148-RJ45V módulo 48-port 10/100 com potência em linha
6 WS-X4148-RJ45V módulo 48-port 10/100 com potência em linha

A capacidade total do infra-estruturo de LAN é conectar e pôr 2,160 Telefones IP.

Os Catalyst 4006 Switch conectam de volta ao Catalyst 6509 por uma das portas GE no supervisor, em uma forma pura do Hub-and-Spoke. Quatro dos cinco assoalhos têm dois Catalyst 4006 Switch quando o quinto assoalho tiver um Catalyst 4006 Switch. Este diagrama ilustra como o Switches é espalhado através dos assoalhos e como conecta de volta ao Catalyst 6509 Switch.

/image/gif/paws/13968/65364.gif

O Catalyst 6509 constitui um ponto de falha único sério. Uma melhoria significativa na Disponibilidade pode ser conseguida adicionar um segundo Catalyst 6509, e pelo homing dual os Catalyst 4006 Switch a ambos os switch centrais usando a porta de reposição GE nos supervisores do Catalyst 4006. Com este projeto, há pouca justificação para a duplicação todos os módulos no Catalyst 6509. Um pouco, os módulos que existem (os supervisores, o GE, e os módulos de FXS) podem ser rachados através dos dois chassis. Contudo, um módulo adicional do oito portas E1 deve ser adicionado de modo que a conectividade de PSTN possa igualmente ser rachada através dos dois chassis. Este projeto igualmente permite os dois CallManagers de Cisco ser conectado aos switch separados. Isto assegura-se de que uma falha do Catalyst 6509 não isole completamente os CallManagers de Cisco.

Um segundo Catalyst 6509 Switch era parte da proposta inicial. Contudo, devido custar considerações, o NB decidiu em um único Catalyst 6509.

O NB segue as recomendações de design de Cisco e tem Telefones IP e dispositivos de dados nos LAN virtuais separados (VLAN). Cada Catalyst 4006 tem sua própria Voz VLAN. Consequentemente, há dois a Voz VLAN pelo assoalho, para um total nove da Voz VLAN. Cada Catalyst 4006 tem 240 portas. Consequentemente, cada Voz VLAN está potencialmente em casa a 240 Telefones IP. Este é um projeto conservador, mas tem a vantagem que limita o impacto se um dispositivo de MAU funcionamento inunda o VLAN com as transmissões. Quando as rotas do Catalyst 6000 Family MSFC entre VLAN, mergulham o desempenho de encaminhamento 3 não é uma edição.

65365.gif

Todos os dispositivos de dados residem em um único, grande VLAN. Isto não segue com as recomendações de design de Cisco. Contudo este era o projeto preferido pelo NB devido a seus operacional e requisitos de manutenção internos. Porque este único VLAN de dados mede todo o Switches, uma tempestade de transmissão da camada 2 neste VLAN tem o potencial afetar todos os Telefones IP. Isto faz o Qualidade de Serviço (QoS) nos Catalyst Switches ainda mais crítico. QoS é discutido mais tarde neste documento.

Este exemplo mostra uma configuração de VLAN típica para uma porta do Catalyst 4006. Este exemplo coloca todas as 48 portas no entalhe 5 na Voz VLAN 110 e no VLAN de dados 11.

set port auxiliaryvlan 5/4-48 110 
set vlan 11 type ethernet state active 
set vlan 11 5/4-48

A rede NB tem estes três limite confiáveis distintos de QoS:

  • Porta do Catalyst 4006 10/100.

  • Porta do Catalyst 6509 10/100 que conecta ao CallManager da Cisco.

  • Porta do Catalyst 6509 10/100 que conecta ao Cisco 7200 Router.

O 10/100 dos módulos do catalizador 4000 no uso mandam um único receber a fila (RX) (1q1t) e dois transmitem as filas (TX) (2q1t). Todas as portas são configuradas com os comandos neste exemplo permitir a segunda fila TX, e pôr quadros com um valor do Classe de serviço (CoS) entre 2 e 7 na segunda fila. Em consequência, todos os pacotes do Real-Time Transport Protocol (RTP) (CoS=5) e todos os Pacotes mirrado (CoS=3) entram na segunda fila, quando todo tráfego restante entrar na primeira fila.

set qos enable
set qos map 2q1t 1 1 cos 0-1
set qos map 2q1t 2 1 cos 2-3
set qos map 2q1t 2 1 cos 4-5
set qos map 2q1t 2 1 cos 6-7

Note que o Catalyst 4006 não apoia nenhum tipo do policiamento. Confia o CoS de todo o quadro recebido em suas portas. Esta não é uma edição enquanto um telefone IP está conectado desde que o comportamento padrão do telefone IP é não confiar o tráfego recebido na porta de PC, e para a reescrever com um CoS de 0. Contudo, um PC conectado diretamente a uma porta do Catalyst 4006 pode potencialmente explorar o QoS se envia dados como os quadros 802.1p. Isto exige um usuário um tanto sofisticado. Contudo, o Network Interface Cards do Windows 2000 e dos Ethernet padrão (NIC) apoia 802.1pq.

A configuração de QoS no Catalyst 6509 é levemente mais involvida desde que as portas no Catalyst 6509 têm uma variedade de estruturas da fila, segundo as indicações desta tabela.

Módulo Fila de recepção Transmitir fila
WS-X6K-SUP1A-MSFC 1p1q4t 1p2q2t
WS-X6416-GBIC 1q4t 2q1t
WS-X6408A-GBIC 1p1q4t 1p2q2t
WS-X6348-RJ45V 1p1q4t 1p2q2t

Toda a porta que tiver uma fila de prioridade estrita põe todos os quadros com o CoS=5 nessa fila à revelia. Contudo, prefere-se ter todo o tráfego de sinalização voip (quadros com CoS=3) na segunda fila sem prioridade. Esta configuração permite este comportamento.

set qos map 1p2q2t tx 2 1 cos 3
set qos map 2q2t tx 2 1 cos 3

As portas GE que conectam aos Catalyst 4006 Switch são dentro de nosso limite confiável. Normalmente o sistema confiaria o CoS dos frames recebidos. Desde que o limite confiável do Catalyst 4006 pode ser comprometido conectando um PC diretamente a uma porta de switch, o tráfego dos Catalyst 4006 Switch é tratado como o não-confiável, e policiado pelo Catalyst 6509. O policiamento é feito por um Access Control List (ACL) que procura os pacotes RTP, magro, H.225, e H.245. Os encabeçamentos de pacote RTP estão reescritos com DSCP=46 quando todos os encabeçamentos de pacote de sinalização voip forem reescritos com DSCP=26. O ACL para este, segundo as indicações deste exemplo, é traçado a todas as portas GE.

set qos acl ip ACL_VOIP dscp 46 udp any any range 16384 32767
set qos acl ip ACL_VOIP dscp 46 udp any range 16384 32767 any
set qos acl ip ACL_VOIP dscp 26 tcp any any range 2000 2002
set qos acl ip ACL_VOIP dscp 26 tcp any range 2000 2002 any
set qos acl ip ACL_VOIP dscp 26 tcp any any eq 1720
set qos acl ip ACL_VOIP dscp 26 tcp any eq 1720 any
set qos acl ip ACL_VOIP dscp 26 tcp any any range 11000 11999
set qos acl ip ACL_VOIP dscp 26 tcp any range 11000 11999 any
set qos acl map ACL_VOIP 3/1-16,4/1-8,

Duas das portas de 10/100 no Catalyst 6509 são usadas para conectar dois a Cisco os CallManagers. Estas são essencialmente portas confiável, mas na rede NB são tratadas como o não-confiável, e as forças CoS=3 do Catalyst 6509 em frames recebidos. Este exemplo mostra a configuração de porta.

set vlan 110 5/2-3
set port qos 5/2-3 cos 3

Uma alternativa, e uma aproximação mais limpa, são configurar o CallManager da Cisco para ajustar o valor do Differentiated Services Code Point IP (DSCP) em todos os pacotes de sinalização voip. Para fazer isto, ajuste os parâmetros de serviço IpTosCm2Cm e o IpTosCm2Dvce a 0x26 no CallManager da Cisco. O Catalyst 6509 pode então ser configurado para confiar o DSCP para os quadros recebidos nessa porta, segundo as indicações deste exemplo.

set port qos 5/2-3 trust trust-dscp

Esta aproximação tem a vantagem que somente os quadros VoIP-controlados, e não cada quadro do CallManager da Cisco, recebem bom QoS. Isto é importante se uma imagem da upgrade do CallManager da Cisco está transferida arquivos pela rede ao servidor do CallManager, ou se as grandes quantidades dos registros dos destalhes da chamada (CDR) estão retiradas rotineiramente o server. Atualmente, este tipo do tráfego igualmente recebe um QoS alto.

Finalmente, uma das portas de 10/100 no Catalyst 6509 é usado para conectar ao Cisco 7200 Series o WAN Router. Esta é igualmente uma porta confiável, mas o ½ atual do ¿  de Cisco IOSï no uso no Cisco 7200 Router não copia o valor DSCP ao campo de CoS. Para superar esta limitação, a porta de switch é tratada similarmente às portas GE (classifique o tráfego de entrada usando o mesmo ACL) e fornece seletivamente QoS baseado neste. Consequentemente, a configuração para a porta de switch de roteador é mostrada neste exemplo.

set vlan 10 5/1
set qos acl map ACL_VOIP 5/1

Infra-estrutura da WAN

O componente de WAN da rede de telefonia do IP NB é pequeno. O Cisco 7200 Series Router na construção DB tem os links MACILENTOS ao NBAP e às torres principais. Contudo, somente o link ao NBAP leva a Voz. Mesmo então há uns links separados entre DB e NBAP para a Voz e os dados. Os problemas de qualidade de voz foram descobertos durante os estágios iniciais do desenvolvimento, e decidiu-se mudar o codec de G.729 a G.711. Esta largura de banda extra exigida, e a Voz e os dados em WAN foram separados consequentemente. A causa destes problemas foi encontrada mais tarde para ser com a carga do telefone IP no uso naquele tempo. Como uma medida conservadora, o NB decidiu ficar com G.711 e separar no curto prazo os links MACILENTOS para a Voz e os dados.

Atualmente o link MACILENTO da Voz consiste em três links E1 físicos que são empacotados junto pelo Multilink PPP (MLP). Devido ao relativamente de alta velocidade do link, nenhum Link Fragmentation and Interleaving (LFI) é exigido. A única característica de QoS exigida está enfileirando-se. O mecanismo de filas preferido é Low Latency Queuing (LLQ). Contudo, isto não trabalhou devido ao Cisco IOS emite com LLQ e MLP, onde o comando service-policy desapareceu da configuração se o link foi para baixo. Como uma solução temporária, as filas de prioridade estiveram no uso. Este exemplo mostra a configuração de WAN atual.

interface Multilink88
 ip address 10.104.209.73 255.255.255.248
 priority-group 1
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
 multilink-group 88

interface Serial4/0
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

interface Serial4/1
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

interface Serial4/2
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

priority-list 1 protocol ip high list 121
priority-list 1 protocol ip medium list 122
priority-list 1 default low
priority-list 1 queue-limit 500 40 60 80

access-list 121 permit udp any any range 16384 32767
access-list 121 permit udp any range 16384 32767 any
access-list 122 permit tcp any any range 2000 2002
access-list 122 permit tcp any range 2000 2002 any
access-list 122 permit tcp any any eq 1720
access-list 122 permit tcp any eq 1720 any
access-list 122 permit tcp any any range 11000 11999
access-list 122 permit tcp any range 11000 11999 any

A configuração de WAN atual é um acordo e não é recomendada para o uso em outras disposições. O plano a médio termo é consolidar sobre a Voz e os dados a um único link MACILENTO, e substituir filas de prioridade com o LLQ. Os links separados para a Voz e os dados exigem o roteamento estático ou o roteamento baseado em política, e as vantagens de usar um protocolo de roteamento dinâmico são perdidas. Filas de prioridade, mesmo com os pacotes de voz que estão sendo atribuídos a fila alta, não garantem que a prioridade estrita está dada aos pacotes de voz. O tráfego do sistema, tal como atualizações de roteamento, Keepalives, e assim por diante ainda toma a preferência sobre pacotes de voz na fila alta.

Verificou-se que o LLQ trabalha corretamente no Cisco IOS Software Release 12.2. Este exemplo mostra o roteador QoS, após o movimento ao LLQ. As larguras de banda são baseadas em 60 atendimentos simultâneos de G.729 (RTP: 60 x 24 kbps = 1440 kbps e sinalização: 60 x 0.5 kbps = 30 kbps).

interface Multilink88
 service-policy output VoIP

class-map VoIP-RTP
 match access-group 121
class-map VoIP-Sig
 match access-group 122

policy-map VoIP
 class VoIP-RTP
  priority 1440
 class skinny
  bandwidth 30

access-list 121 permit udp any any range 16384 32767
access-list 121 permit udp any range 16384 32767 any
access-list 122 permit tcp any any range 2000 2002
access-list 122 permit tcp any range 2000 2002 any
access-list 122 permit tcp any any eq 1720
access-list 122 permit tcp any eq 1720 any
access-list 122 permit tcp any any range 11000 11999
access-list 122 permit tcp any range 11000 11999 any

Telefonia IP

Telefones IP e suas conexões com o Switch

A construção DB tem aproximadamente 750 o telefone IP 7960s. Os Telefones IP conectam 10/100 às portas no Catalyst 4006, e recebem a potência em linha do interruptor. Os PC conectam às portas de switch na parte de trás do telefone IP, como representado neste diagrama.

/image/gif/paws/13968/65373.gif

Os Telefones IP e os PC estão em VLAN separados e em sub-redes IP.

Planejamento da instalação

Todos os Telefones IP recebem a potência em linha das placas de linha do Catalyst 4006. O Switches ele mesmo é posto por três fontes de energia AC dos em-chassis. A potência em linha, contudo, é originado externamente da fonte de potência auxiliar de Catalyst 4006 (WS-P4603). A prateleira de força tem três fontes de alimentação. Cada um fornece 1050W em -52V DC. Isto é suficiente para pôr um Catalyst 4006 Switch inteiramente povoado com o Cisco IP Phone 7960s conectado a todas as 240 portas.

/image/gif/paws/13968/65366.gif

Todos os Catalyst 4006 Switch fogem um Uninterrupted Power Supply (UPS). Isto permite que continuem a operação por duas horas no caso de uma falha de energia. Os CallManagers de Cisco conectam a UPS de quatro horas.

Cisco CallManager

O modelo da distribuição do CallManager NB é único local com processamento de chamada centralizada. Se pode discutir que o modelo é de fato multi-local devido ao link MACILENTO ao NBAP e ao gateway associado encontrado lá. Mas este fato pode (geralmente) seja ignorado porque nenhum controle de admissão da chamada (CAC) é exigido através de WAN. Isto é porque o número de atendimentos através de WAN é limitado implicitamente pelo número de troncos que conectam o gateway ao PBX.

O Cluster do CallManager daCisco NB consiste em dois Cisco Media Convergence Server 7835s (MCS-7835). Um CallManager executa a função da publicação de base de dados, e o outro subscreve ao base de dados. Todo o registro dos Telefones IP com o subscritor como o CallManager da Cisco principal, e usa o editor como o CallManager da Cisco secundário.

Duas regiões são configuradas: NBAP e DB. O gateway no NBAP é o único dispositivo na região NBAP, todos os outros dispositivos está na região DBS. O projeto pretendido é usar G.711 para todos os atendimentos dentro dos DB que constroem, e uso G.729 somente para atendimentos através de WAN. Atualmente, contudo, os atendimentos através do link MACILENTO são igualmente G.711.

Os Telefones IP na região DBS têm uma extensão de cinco dígitos na escala de 17000 a 17999. Há outros cinco locais NB em Singapura que têm uma mistura de quatro e extensões de cinco dígitos. Esta tabela mostra os locais NB Singapura.

Nome de site Código do site Dígitos
Departamento de ligação de Cingapura DB 5
Impressão do Acme NB NBAP 5
Acme que constrói A ABA 4
Acme que constrói B ABB 5
Impressão de Douglas DP 4
Impressão de Grant GP 4

Os Ramais estão atribuídos de modo que o primeiro dígito determine excepcionalmente se a extensão é quatro ou cinco dígitos. Os usuários de telefone IP podem discar toda a extensão PBX NB Singapura discando os quatro ou a extensão de cinco dígitos.

Como discutido mais tarde na seção da integração de gateway, há três tipos de gateways:

  • Um gateway de H.323 do Cisco 7200 que conecta ao NB PBX do legado uma rede.

  • Três gateways do Catalyst 6509 E1 que conectam ao PSTN.

  • Dois gateways FXS do Catalyst 6509 24-port que conectam ao correio de voz.

Isto é refletido na configuração do grupo de rotas do CallManager da Cisco. Um grupo de rotas existe para cada um dos três tipos de gateway. Esta tabela esboça as características de cada grupo de rotas.

Grupo de rotas Plataforma /porta do entalhe Tipo de porta Prioridade
DB VM Catalyst 6509 Switch 6/1-24 7/1-24 FXS FXS 1 2
DB PSTN Catalyst 6509 Switch 8/1 8/2 de 8/3 PRI PRI PRI 1 2 3
NBAP legado Cisco 7200 Router 5/1-2 PRI 1

Os atendimentos aos vários destinos são distribuídos como segue:

  • Os atendimentos ao PSTN usam o grupo de rotas DB PSTN. Não há nenhum backup.

  • Os atendimentos ao correio de voz usam o grupo de rotas DB VM. Não há nenhum backup.

  • Os atendimentos ao serviço de telnet NB usam o grupo de rotas de NBAP existente.

  • Os atendimentos a uma extensão PBX NB Singapura usam o grupo de rotas de NBAP existente como o grupo de rotas preliminar, e DB PSTN como o grupo da rota secundária.

Tudo que permanece agora é definir testes padrões da rota apropriada e os ligar aos grupos de rotas. Isto é direto para os primeiros três artigos alistados acima, porque somente uma lista da rota única é exigida. As coisas obtêm levemente mais involvidas com o último artigo devido ao grupo da rota de backup. O caminho preferido para um atendimento de um telefone IP a uma extensão PBX é através do grupo de rotas de NBAP existente. Se este gateway é não disponível, os atendimentos estão distribuídos com o PSTN através do grupo de rotas DB PSTN. Quando isto acontece, os dígitos têm que ser prefixados à extensão discada a fim criar o número de telefone completo PSTN. Os dígitos prefixados dependem do local que está sendo chamado, daqui, cada local deve ter uma lista diferente da rota. Porque há cinco locais NB com PBX, e diversos prefixos PSTN pelo local, terminam acima com dez lista da rota.

Este diagrama mostra todas as lista da rota NB. Os dois ou o número com três dígitos incluídos em nome da maioria de lista da rota refletem os dígitos que são prefixados à extensão chamada, sempre que os atendimentos são enviados ao grupo de rotas DB PSTN.

/image/gif/paws/13968/65367.gif

Determinados usuários de telefone IP NB são restringidos nos números que podem chamar. Isto é controlado colocando as rotas padrão e os Ramais do telefone IP em um número de separações. As separações são agrupadas então junto em um Calling Search Space. Os Telefones IP pertencem a um Calling Search Space e podem somente chamar os números contidos nas separações nesse espaço de pesquisa. Esta tabela alista os espaços de pesquisa e as separações do CallManager da Cisco NB.

O espaço de pesquisa Separações Descrição
Convidado Atendente de chamada do Convidado DBS NB SGP DB do usuário DB Entrada normal do telefone do usuário DB e o outro recepcionista da extensão PBX do telefone de área pública NB Singapura
Usuário Atendente de chamada do Convidado DBS NB SGP IDD DB do telnet SGP PSTN do usuário NB GSDN NB DB Telefone do usuário normal DB — Chamadas internacionais por chamadas local mundiais da rede NB na entrada de Singapura e no outro recepcionista das chamadas internacionais da extensão PBX dos telefones de área públicas NB Singapura

Integração de correio de voz

Os DB usam o sistema de correio de voz octel. Isto foi escolhido porque é um padrão mundial NB, e a rede de correio de voz entre os vários sistemas foi desejada.

O CallManager da Cisco conecta ao sistema de correio de voz octel por meio de dois cartões 24-port FXS no Catalyst 6509 Switch. Somente 30 das 48 portas disponíveis são usadas. Um link de um Simplified Message Desk Interface (SMDI) 9600 bps conecta o CallManager da Cisco principal ao dispositivo octel.

O sistema octel é conectado igualmente à rede Octel corporativa NB. Isto é feito por meio de quatro portas do escritório de câmbio internacional (FXO) no dispositivo octel que conectam a Lucent um Definity PBX velho. Este diagrama mostra como o sistema octel DB conecta ao novo e ao velho mundo.

/image/gif/paws/13968/65368.gif

Nota: O projeto inicial não incluiu o PBX. Um pouco, a ideia era à rede o correio de voz transversalmente através do cartão 24-port FXS e da rede voip. Mas durante o piloto, as edições foram encontradas na maneira que o cartão FXS segurou os tons do Dual Tone Multi-frequency (DTMF) do dispositivo octel. Como uma ação alternativa, o cartão 24-port FXS foi substituído com um Cisco IOS gateway. Isto trabalhado muito bem, mas o NB preferiu a solução PBX-baseada.

Vale notando as características de elasticidade da solução do correio de voz. Além do que o sistema de correio de voz, há outros pontos de falha únicos:

  • O link SMDI não é redundante: Uma falha do CallManager da Cisco principal tomará o sistema de correio de voz fora de serviço. Se esta situação ocorrer, a estratégia NB é mover manualmente o cabo SMDI para Backup do CallManager da Cisco. Alternativamente, um divisor SMDI permitiria que ambos os CallManagers fossem conectados ao mesmo tempo, e permite-os o failover automático.

  • Atualmente ambos os cartões 24-port FXS residem no mesmo chassi do Catalyst 6509. Uma falha do Catalyst 6509 tomará o sistema de correio de voz fora de serviço. Como discutido mais cedo neste documento, há muito a ser ganhado em termos da resiliência adicionando um segundo Catalyst 6509.

Integração do gateway

A tabela a seguir alista os três tipos diferentes de Gateways de voz na rede NB.

Plataforma Tipo de interface Número de portas Protocolo Conexão a
Catalyst 6509 PRI/E1 8 x 30 canais Magro PSTN
Catalyst 6509 FXS Analógico 2 x 24 Magro Correio de voz
7206VXR PRI/CAS/E1 2 x 30 canais H.323 Legado PBX

O Catalyst 6509 guarda um único cartão do oito portas E1. Três destas oito portas conectam ao PSTN por meio do PRI. Cada porta E1 tem seu próprio endereço IP de Um ou Mais Servidores Cisco ICM NT e suas funções de porta como gateways independentes. O roteamento de chamada a e dos gateways é controlado pelo CallManager da Cisco por meio do protocolo mirrado. Os usuários discam um número PSTN discando 0, seguido pelo número PSTN. As chamadas recebidas têm os dígitos principais descascados, e o atendimento é distribuído ao telefone IP chamado baseado nos últimos cinco dígitos.

Os usuários discam o '9' para selecionar uma linha exterior, e o CallManager da Cisco remove este dígito antes de apresentar o atendimento ao PSTN. O NB tentou dois métodos de remover o dígito. O primeiro método inclui um “ponto” na rota padrão no CallManager da Cisco, e todos os dígitos do PRE-ponto são rejeitados antes de apresentá-lo ao PSTN. O segundo, e o método preferido, são configurar o descarte como parte do gateway setup no CallManager da Cisco. Isto é feito ajustando o número de dígitos para descascar o campo a um. Este segundo método é melhor porque preserva o '9' principal em que o número é armazenado no diretório colocado dos atendimentos no telefone IP. Isto significa que o usuário pode mais tarde riscar o número do diretório sem ter que pressionar editdial e adicionar o '9' principal.

Os gateways FXS são usados unicamente para o correio de voz. Estes gateways são controlados pelo CallManager da Cisco por meio de magro.

O gateway do Cisco 7200 fornece a Conectividade entre a rede de telefonia do IP em DB e a rede mundial do NB PBX. Este gateway é o único dispositivo voip situado não fisicamente na construção DB: É ficado situado na construção nbap, e alcançado por meio de um link MACILENTO.

O gateway do Cisco 7200 é cabido com um único adaptador da porta E1 da dois-porta, e usado H.323 para falar ao CallManager. Ambas as portas E1 conectam a Nortel um meridiano situado no NBAP. Um USOS de porta QSIG e a outra sinalização associada a canal (CAS) dos usos falar ao PBX. Os atendimentos às extensões PBX de Singapura estão distribuídos abaixo da porta QSIG, quando as chamadas internacionais, usando a rede de voz privada (telnet), forem distribuídas através da porta de CAS.

A mistura de CAS e de QSIG complica a instalação. CAS é exigido para fornecer o acesso ao discagem internacional código-protegido do número de identificação pessoal (PIN) pela rede de voz telnet mundial. Quando um usuário disca este serviço, discam 313xxxxxx, onde xxxxxx são um código PIN do seis-dígito. O aplicativo Meridian que autentica este código PIN não parece ser apoiado pelo PRI. Daqui, a necessidade de usar por esse motivo CAS em um dos dois troncos.

Isso dito, CAS que sinaliza mais fácil provado obter indo do que o tronco de QSIG. Entre as edições encontradas eram os timeslot que travam acima no meridiano e no desacordo no número de canal B. Quase todas as edições tiveram que fazer com uma má combinação dos parâmetros de configuração no Cisco 7200 e no lado meridiano. Estas edições eram resolved depois que o Cisco IOS forneceu uma configuração de meridiano de trabalho.

Uma cópia da configuração de meridiano é incluída abaixo. Esta configuração é de uma opção de Meridiano 11C, Software Release 24.24 running. Os seguintes pacotes de softwares são exigidos a fim ativar esta configuração.

QSIG      263
QSIGGF    305
MASTER    309
QSIG-SS   316
ETSI-SS   323

A seguinte configuração é do bloco de dados da rota de configuração.

TYPE  RDB     (Route Data Block)
CUST  00      (Customer Number)
DMOD
ROUT  xx      (Route Number)
DES           (Trunk Description)
TKTP  TIE     (Trunk type - Tie Line or DID)
ESN   NO 
RPA   NO
CNVT  NO
SAT   NO
RCLS  INT     (Route Class - Internal or External)
DTRK  YES     (Digital Trunk - YES)
BRIP  NO
DGTP  PRI2    (Digital Group Type - PRI 30B + D)
ISDN  YES     (YES when DGTP is PRI or PRI2)
MODE  PRA     (ISDN/PRA Route)
IFC   ESGF    (ESGF req QSIG & QSIF GF Pkgs)
SBN   NO
PNI   00000
NCNA  NO
NCRD  NO
CTYP  UKWN
INAC  NO
ISAR  NO
CPFXS YES
DAPC  NO
INTC  NO
DSEL  VOD
PTYP  DTT
AUTO  NO
DNIS  NO
DCDR  NO
ICOG  IAO     (Bothway Trunk In and Out (IAO))
SRCH  RRB
TRMB  YES
STEP
ACOD  xxxx    (Trunk access code)
TCPP  NO
TARG  03
BILN  NO
OABS
INST
ANTK
SIGO  STD
MFC   NO
ICIS  YES
OGIS  YES
PTUT  0
TIMR  ICF     512
OGF   512
EOD   13952
NRD   10112
DDL   70
ODT   4096
RGV   640
GTO   896
GTI   896
SFB   3
NBS   2048
NBL   4096
IENB  5
TFD   0
VSS   0
VGD   6
DTD   NO
SCDT  NO
2 DT  NO
DRNG  NO
CDR   NO
NATL  YES
SSL
CFWR  NO
IDOP  NO
VRAT  NO
MUS   NO
PANS  YES
FRL   0 x
FRL   1 x
FRL   2 x
FRL   3 x
FRL   4 x
FRL   5 x
FRL   6 x
FRL   7 x
OHQ   NO
OHQT  00
CBQ   NO
AUTH  NO
TTBL  0
PLEV  2
OPR   NO
ALRM  NO
ART   0
PECL  NO
DCTI  0
TIDY  xx
SGRP  0
AACR

Esta configuração é do canal D.

ADAN  DCH 12      (D-Channel Number assigned by programmer)
CTYP  MSDL        (D-Channel Card type) 
CARD  02          (Card Location)
PORT  1           (Port Number) 
DES   CISCO_5300  (Description)
USR   PRI         (User type - PRI for ISDN PRA only)
DCHL  2           (Loop the D-Channel will be associated with)
OTBF  32          (Output request buffer)
PARM  RS422 DTE   (Default)
DRAT  64KC        (64kb/s Clear - Don't change) 
CLOK  EXT         (Clock Source - External)
NASA  NO          (Default NO)
IFC   ESIG        (ETSI Q Reference Signaling - MSDL D-Channel ONLY) 
ISDN_MCNT  300    (Default)
CLID  OPT0        (Opt0 is default for ESIG and ISIG interfaces)
CO_TYPE  STD      (100% Compatible)
SIDE  NET         (Network or User Side)
CNEG  2           (2 = Channel is indicated - alternative is accepted)
RLS   ID  **      (Default)
RCAP  COLP        (COLP is default for ESIG, ISIG interfaces)
MBGA  NO          (Default)
OVLR  NO          (Default)
OVLS  NO          (Default)
T310  120         (Default)
T200  3           (Default)
T203  10          (Default)
N200  3           (Default)
N201  260         (Default)
K     7           (Default)

Esta é uma configuração para os temporizadores do laço para a relação da linha tie PRI.

LOOP 2

MFF    AFF
ACRC   NO
ALRM   REG
RAIE   NO
G1OS   YES
SLP    5       24 H    30    1 H
BPV    128    122
CRC    201     97
FAP    28       1
RATS   10
GP2    20     100 S    12 S    12 S    4 S
MNG1   60 S
NCG1   60 S
OSG1   60 S
MNG2   15 S
NCG2   15 S
OSG2   15 S
PERS   50
CLRS   50
OOSC   0

Esta configuração é do canal B.

TN     00x 0x      (LEN, TN (Terminal Number))
TYPE   TIE         (Trunk Type - Tie Line)
CDEN   SD          (Single Density Card
CUST   0           (Customer 0)
TRK    PRI2        (Trunk Type)
PDCA   x           (Pad Category Table)
PCML   A           (A-law or Mu-Law)
NCOS   0           (Network Class of Service)
RTMB   x y         (Route Member- x is router no., y is member no.)
B-CHANNEL SIGNALING
TGAR   0           (TGAR Restricted Dialing Leave as 0)
AST    NO          (Default)
IAPG   0           (Default)
CLS    CTD DIP WTA LPR APN THFD XREP BARD
P10    VNL         (Class of services)
TKID

A configuração de gateway para os dois troncos E1 é mostrada aqui. Observe que o gateway atua como o lado da rede, quando o meridiano for o lado do usuário.

controller E1 5/0
 pri-group timeslots 1-31

!-–– Defines PRI trunk.


controller E1 5/1
 framing NO-CRC4
 ds0-group 0 timeslots 1-15,17-31 type e&m-wink-start

!-–– CAS trunk.


interface Serial5/0:15
 isdn switch-type primary-qsig

!-–– Defines Q.SIG signaling.

 isdn protocol-emulate network

!-–– The network side.

 isdn incoming-voice voice
 isdn send-alerting
 isdn sending-complete

O gateway tem 15 POTS dial peer. A maioria dos dial peer indicam o tronco de QSIG, refletindo as várias extensões PBX que são alcançáveis no lado PBX.

Os dial peer restantes indicam o tronco CAS, atendimentos de direção à rede de voz telnet. Igualmente observe que o tronco de QSIG está configurado para incluir um Progress Indicator com um valor de 8 quando envia uma mensagem de alerta de volta ao PBX. Isto diz ao PBX que o gateway está fornecendo o tom de chamada de retorno in-band, e o PBX abre o caminho de áudio mesmo antes que um atendimento esteja respondido pelo telefone IP.

dial-peer voice 33 pots
 preference 1
 destination-pattern 33.......
 direct-inward-dial
 port 5/1:0

!-–– Calls routed out of the CAS trunk.

 forward-digits all
!
dial-peer voice 313 pots
 destination-pattern 313......
 direct-inward-dial
 port 5/1:0
 forward-digits all
!
dial-peer voice 40000 pots
 destination-pattern 4....
 progress_ind alert enable 8

!-–– Gateway to provide ringback.

 direct-inward-dial
 port 5/0:15

!-–– Calls routed out of the QSIG trunk.

 forward-digits all
!
dial-peer voice 8 pots
 destination-pattern 8T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 7 pots
 destination-pattern 7T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 6 pots
 destination-pattern 6T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 5 pots
 destination-pattern 5T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 16 pots
 destination-pattern 16...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 13 pots
 destination-pattern 13...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 2 pots
 destination-pattern 2T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 1000 pots
 destination-pattern 1...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 10 pots
 destination-pattern 0...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 3 pots
 destination-pattern 3...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 508200 pots
 destination-pattern 5082..
 progress_ind alert enable 8
 port 5/0:15
 forward-digits all

Há somente dois dial peer de VOIP, um apontando a cada CallManager da Cisco. Os dial peer são idênticos à exceção da preferência, que se assegura de que os atendimentos estejam distribuídos ao CallManager da Cisco principal quando disponíveis. A instalação do progress_ind permite 3 diz o gateway para sinalizar ao PBX, por um Progress Indicator no mensagem setup, que a chamada originada é não ISDN. Finalmente, h225 o intervalo tcp estabelece 3 diz o gateway para esperar um máximo de três segundos ao estabelecer uma sessão H.225 com o CallManager da Cisco. Se o CallManager da Cisco não responde dentro de três segundos, o gateway tenta o CallManager da Cisco secundário.

dial-peer voice 17000 voip
 preference 1

!-–– Route to primary Cisco CallManager is preferred.

destination-pattern 17...
 progress_ind setup enable 3

!-–– Progress indicator = non-ISDN.

 voice-class h323 10
 session target ipv4:10.66.184.13
 dtmf-relay cisco-rtp h245-signal h245-alphanumeric
 codec g711ulaw
 ip precedence 5
 no vad
!
dial-peer voice 17001 voip
 preference 2
 destination-pattern 17...
 progress_ind setup enable 3
 voice-class h323 10
 session target ipv4:10.66.184.14
 dtmf-relay cisco-rtp h245-signal h245-alphanumeric
 codec g711ulaw
 ip precedence 5
 no vad

voice class h323 10
 h225 timeout tcp establish 3

Algumas das edições as mais persistentes encontradas durante o lançamento do projeto de telefonia IP NB referiram-se o eco. As edições principais do eco foram experimentadas pelos usuários de telefone IP quando chamaram determinados números através do gateway do Cisco 7200. O esforço que entrou na tentativa reduzir o eco era extensivo, e as tentativas da informação seguinte para capturar as partes desta experiência que podem ser úteis a outras disposições.

A expectativa inicial pela equipe de design de telefonia IP era para que o gateway do Cisco 7200 forneça a Conectividade entre o lado de VoIP e um único PBX no NBAP. Como se veio a verificar, o que de fato era fornecido era Conectividade entre o lado de VoIP e a rede de voz muito grande, mundial NB. A rede de voz NB tem um legado do seus próprios, incluindo um número de problemas de eco. No passado, o NB tentou ajustar os níveis da potência dos vários Nós nesta rede para minimizar a quantidade de eco. A rede a que o gateway do Cisco 7200 estava conectando era uma rede com problemas de eco existentes. Igualmente teve níveis de variação da potência de sinal, segundo o destino do atendimento. Esta era uma integração difícil.

Introduzindo uma solução da voz empacotada, com seus atrasos adicionais, os problemas de eco foram agravados. Em um esforço para segurar isto, os seguintes ajustes foram feitos.

  • Os canceladores de eco do Cisco 7200 foram ajustados a sua configuração mais agressiva.

  • O ganho de entrada foi abaixado.

  • A atenuação de saída aumentou nos dois troncos E1.

Quando isto reduziu o eco, teve o efeito secundário indesejável que os níveis do volume, ao chamar determinados destinos na rede de voz NB, eram demasiado baixos e os usuários se estavam queixando. Devido à má combinação dos níveis de sinal no lado do legado, havia ninguém combinação de ganho e de atenuação que seriu atendimentos a e de todos os destinos. O que trabalhado bem para atendimentos a Hong Kong criou o eco em atendimentos a Coreia. O que trabalhado para Coreia conduziu aos problemas de Hong Kong do volume baixo. A configuração abaixo mostra a configuração de comprometimento atual para as portas de voz no gateway do Cisco 7200.

voice-port 5/0:15
 input gain 0
 output attenuation 3
 echo-cancel coverage 32
 compand-type u-law
 cptone SG

voice-port 5/1:0
 input gain -2
 echo-cancel coverage 32
 compand-type u-law
 cptone SG
 timeouts interdigit 5
 timeouts wait-release infinity
 timing percentbreak 60

A engenharia de desenvolvimento está trabalhando atualmente em melhorar as capacidades do cancelamento de eco de algum Produtos da Cisco. O NB está esperando estas melhorias a fim reduzir mais o eco.

As soluções alternativa foram propostas ao NB, mas o cliente decidiu esperar os aprimoramentos do Cisco. Dois propuseram que as ações alternativas estivessem discutidas abaixo na esperança que outros projetos podem tirar proveito delas. A lição geral aprendida do NB é que um alerta do flag vermelho deve ser levantado cedo se a solução de telefonia do IP proposta conecta a um grande legado de rede de voz privado. Fazendo isso, estas ações alternativas podem ser projetadas e custado na solução desde o início.

  • Workaround 1 — Introduza canceladores de eco da terceira parte entre o Cisco gateway e o PBX. A tecnologia de eliminação de eco Cisco pode atualmente cancelar as caudas do eco que são atrasadas menos então a Senhora 32. O sinal ecoado deve ser sujeito a uma perda de retorno de eco (ERL) pelo menos de DB 6, isto é, o sinal recebido do eco deve ser pelo menos DB 6 mais baixo do que originalmente o sinal transmitido. Para que seja de valor, o desempenho do anulador da terceira parte deve exceder os valores acima.

  • Workaround 2 — Aumente o número de troncos entre o Cisco gateway e o PBX. Isto permite que cada tronco seja configurado com uma definição de ganho/atenuação diferente. Os atendimentos podem então ser distribuídos através do tronco com a maioria de características de eco adequadas. Por exemplo, os atendimentos a Hong Kong podem atravessar o tronco 1 quando os atendimentos a Coreia atravessarem o tronco 2. O PBX igualmente precisa de poder distribuir atendimentos através do tronco correto, com base em onde o atendimento origina.

Provisionamento de DSP para conferência e transcodificação

Embora G.711 seja usado atualmente durante todo a rede, a intenção é usar G.729 através do link MACILENTO entre DB e NBAP. O projeto levou em conta este atribuindo recursos de conferência do processador do sinal digital do hardware (DSP). Os recursos do hardware residem no Catalyst 6509. Recorde que somente três das oito portas E1 estão no uso para a conectividade de PSTN. Três das cinco portas permanecendo são usadas para Conferências.

Há duas portas não utilizadas no módulo do Catalyst 6509 E1 que são recursos transcoding estabelecidos. Não há atualmente uma necessidade para transcoding, mas a necessidade elevarará se o NB decide distribuir um server da resposta de voz interativa IP (IVR).

Versões de software

A tabela a seguir alista as versões de software usadas na rede NB então este documento foi redigido.

Dispositivo Versão
Catalyst 6509 5.5(3)
Catalyst 4006 6.1(1)
Cisco 7260VXR 12.1(3a)XI5
Cisco CallManager 3.0(8)
Telefone IP 7960 P003Q301
WS-X6608-E1 C001W300
WS-X6624-FXS A002S300

Gerenciamento de Rede

As ferramentas de gerenciamento da rede não são usadas atualmente para controlar a rede de telefonia do IP NB.

Lições aprendidas

Anomalias, advertências e resoluções descobertas

A tabela a seguir resume as questões principal encontradas durante o desenvolvimento. Os detalhes destas edições são discutidos mais cedo neste documento.

Caveat Resolução
Ecoe ao conectar a rede de voz de pacote de informação a um grande legado de rede de voz. Os troncos adicionais da comissão e variam o ganho/atenuação de modo que os atendimentos possam ser distribuídos através de um tronco com uma configuração apropriada. Distribua canceladores de eco da terceira parte. Await melhorou a tecnologia de eliminação de eco Cisco.
Os parâmetros combinados mal QSIG no gateway e no PBX tomam partido. Configurações de PBX de trabalho Obtain de uma site existente usando uma instalação similar.
Dígito para selecionar a linha exterior não armazenada no diretório dos colocar-atendimentos. Rejeite o dígito principal em uma configuração de gateway e não use uma ação do descarte do PRE-ponto na rota padrão.

Casos de TAC

A tabela a seguir alista todas as edições que conduziram a um caso de TAC. Igualmente são incluídos outros problemas significativos que foram resolvidos localmente pelo equipe de desenvolvimento.

- - - - - - - - - -
Caso # Descrição Estado e definição
B124306 Fechamento de canal QSIG. Resolvido inicialmente reconfigurando o parâmetro do Channel Negotiation LD17 (CNEG) em Nortel PBX de Option(2) a Option(1). Contudo, os sintomas do problema reapareceram após alguma hora. Subseqüentemente, o fornecedor de PBX mudou a configuração QSIG PRI no PBX de ESIG (configuração QSIG GF) a ESGF (configuração QSIG europeia). Após a alteração, o fechamento do canal cessado de ocorrer mas somente os 15 canais superiores era funcionais. Para retificar o problema, o comando ISDN contiguous-bchan foi removido do roteador VoIP.
A612818 Má combinação do canal B onde Nortel PBX usa o canal 31 como o canal de controle quando o cisco voice gateway PRI usar o canal 16. Resolvido configurando o comando ISDN contiguous-bchan na relação PRI QSIG. Este comando é usado especificar o canal do portador contíguo que segura de modo que os canais B 1 a 30 (canal de salto 16) tracem aos timeslot 1 a 31. Isto está disponível para relações E1 PRI somente quando preliminar-QSIG o tipo de switch opção é configurado usando o comando isdn switch-type.
B124306 Eco. Há duas encenações em que os 7200 canceladores de eco não podem poder cancelar para fora um eco. Cenário 1: O eco é demasiado alto para que os anuladores cancelem para fora. Cenário 2: O eco é atrasado mais pela Senhora de 32, que é além da cobertura dos 7200 anuladores. Cenário 1: Fazer ajustes à atenuação de saída e ao ganho de entrada no gateway de voz e nos estofamentos no PBX de forma excelente melhorou a situação do eco. As configurações final são:
  • Ganho de entrada do Cisco 7200 PRI = 0
  • Atenuação de saída de Ciisco 7200 PRI = 3
  • Ganho de entrada de CAS do Cisco 7200 = -2
  • Atenuação de saída de CAS do Cisco 7200 = 0
  • Atenuação PBX PRI TX = 2
  • Atenuação PBX PRI RX = 4
  • Atenuação PBX CAS TX = 0
  • Atenuação PBX CAS RX = 5
As repetições residuais ocorrem como estático propalam nos primeiros 1 a 2 segundos do córrego RTP. A duração é inevitável para que o algoritmo de adaptação treine no fluxo de áudio e perfile para fora um cancelamento efetivo. Cenário 2: Uma cauda do eco mais da Senhora de 32 é improvável em uma rede de voz analógica. Contudo, pode ocorrer em uma rede de voz de pacote de informação. Porque a cobertura de cancelamento de eco está atualmente em um máximo de 32 Senhora, o funcionamento de desenvolvimento é corrente produzir um código que integre um cancelador de eco complacente de G.168 da terceira parte (com comprimento da cauda pelo menos da Senhora 64).
Ruído do biscoito, qualidade de voz deficiente (carga do telefone). Firmware P003Q301 carregado no telefone IP. A carga Q é mais robusta para o tremor e o atraso.
Nenhum ringback ao telefone IP ao chamar o número externo pelo QSIG. O gateway não gerencie o tom de chamada de volta a menos que o mensagem setup contiver um progress indicator (PI) de 3 (o endereço de origem é não ISDN). Isto é porque o gateway supõe aquele sem um PI de 3, o switch de origem é ISDN e espera o interruptor gerar pelo contrário o tom de chamada de volta. Sem um PI de 3 que ajustam-se, o gateway está esperando o switch ISDN gerar o anel, mas o switch ISDN não está gerando o anel. Isto pode ser devido a uma edição do funcionamento entre redes ISDN. Para permitir o gateway de gerar o tom de chamada de volta, configurar o progress_ind no dial peer de VOIP.
dial-peer voice 1 voip
 destination-pattern 8...
  progress_ind setup enable 3
  session target ipv4:192.168.2.10
  dtmf-relay h245-alphanumeric
  codec g711ulaw
  ip precedence 5
O acima forçará então o gateway para fornecer o tom de chamada de volta para os atendimentos que saem no ISDN esse tandem que dial peer de VOIP.
A695422 Há uma diferença nas durações de DTMF. Isto pode ser causado pelo fato de que o catalizador não está reconhecendo corretamente os toms DMTF enviados pelo sistema de correio de voz. Ao vir de um cartão do catalizador, a duração de DTMF é a Senhora 300 à revelia. Ao vir do correio de voz, a duração é a Senhora 130. A especificação de Octel exige que pelo menos cinco dígitos estão precisados por segundo para que o aperto de mão trabalhe corretamente. O CallManager da Cisco envia atualmente o H245-SIGNALLING com uma duração da Senhora 300, fazendo um total de 300*5 = o segundo 1.5. Nesta duração, o correio de voz octel terá cronometrado para fora antes que os encabeçamentos da rede de correio de voz estejam recebidos completamente. Contorneou o módulo de FXS 24-port (dispositivo mirrado) com um gateway do Cisco 3640 (dispositivo de H.323) carregado com um cartão FXS.
Áudio de sentido único para atendimentos através do gateway de voz. O problema é causado pelo gateway que escolhe um endereço IP de Um ou Mais Servidores Cisco ICM NT a não ser aquele da interface de loopback. O laço de retorno é a relação de que o tráfego do CallManager deixa o roteador. Põe o endereço IP de Um ou Mais Servidores Cisco ICM NT do srcaddr do ligamento do h323-gateway voip sobre esta relação para forçar o roteador a usar o endereço IP especificado como o endereço de origem RTP.
interface Loopback0
 description ::: Loopback for BGP peering
 ip address 192.170.94.34 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip bind srcaddr 192.170.94.34
No CallManager da Cisco, mude o dispositivo de gateway de H.323 de um nome a um endereço IP de Um ou Mais Servidores Cisco ICM NT. Isto igualmente impede todas as questões indesejadas com consultas reversas DNS/hosts.
O CallManager da Cisco tem um problema conhecido onde seus serviços deteriorem lentamente ao longo do tempo devido ao escape de memória. Um reparo provisório era recarregar numa base semanal os CallManagers de Cisco. Windows 2000 Service Pack instalado 1 e um reparo da memória virtual aos servidores do CallManager. Como uma precaução extra, o NB foi recomendado para recarregar semanalmente os CallManagers para que os meses subsequente assegurem a estabilidade máxima. O NB deve decidir parar as repartições semanais quando julgado apropriado.
A944914 O WFQ não trabalha sobre o Multi-PPP sobre os links múltiplos do 2 Mbps. O comando Service-policy para a implementação de LLQ desaparece depois de algum tempo dando o comportamento MACILENTO indeterminado. Três opções estão disponíveis para segurar esta edição:
  • Para todas as relações no pacote MPPP, ajuste a largura de banda nas interfaces serial pelo menos a 4800 (4/3 x 3600).
  • Elevação a 12.2.018 que é uma versão pré-versão de 12.2. Este é DE (não TAC) apoiado. A edição é fixada nesta versão.
  • Execute filas de prioridade para um outro sabor de QoS MACILENTO.
O botão Message Button no telefone não estava funcionando inicialmente. Os seguintes ajustes são exigidos para permitir o botão Message Button:
  • Nos parâmetros de serviço, entre no número de extensão do correio de voz como o valor para o campo do VoiceMailDN.
  • Nos parâmetros empresariais, entre no número de extensão do correio de voz como o valor para o campo de MessageDirectoryNumber.
Nível alto do tráfego de broadcast do cartão E1 (WS-X6608) devido a um erro no código do Address Resolution Protocol (ARP) no módulo do gateway skinny do Catalyst 6509. Como uma ação alternativa, os cartões E1 (WS-X6608) são configurados em um VLAN separado. Isto reduz o tamanho do cache ARP a um máximo de três entradas. Ao mesmo tempo, um upgrade de skinny gateway firmware novo (D004R300) foi carregado nos módulos para fixar o problema.
Perda de CoS através do link MACILENTO. Um dos novos recursos no Cisco IOS Software Release 12.1(5)T e Mais Recente é mapeamento de TOS-à-CoS. Com isto, o roteador pode ajustar o CoS=ToS antes de enviar qualquer coisa ao Catalyst 6509. O Catalyst 6509 é configurado então para o Trust-cos na porta de roteador, e pegara o valor DSCP interno de lá. Cisco QoS mantém o ToS e o CoS avalia usar o DSCP.
A tabela ARP foi corrompida, tendo por resultado uma perda de fluxo de áudio ao alcançar o sistema de correio de voz pelo cartão WS-X6624. Como uma ação alternativa, os cartões FXS (WS-X6624) são configurados em um VLAN separado. Isto reduz o tamanho do cache ARP a um máximo de três entradas. Ao mesmo tempo, um upgrade de skinny gateway firmware novo (A002S300) foi carregado nos módulos.
Frequente a suspensão das portas FXS conectadas ao dispositivo do correio de voz octel. Este problema parece comum com o sistema de correio de voz octel com Conectividade (FXO) análoga. O número de portas de suspensão pode variar quando o dispositivo de correio de voz é conectado com os sistemas PBX diferentes. Os PBX tradicionais têm normalmente a capacidade para restaurar portas penduradas individuais sem impactar a operação total do correio de voz. Cisco facilitou um utilitário DickTracy que permitisse usuários de restaurar e monitorar portas individuais no cartão FXS. O utilitário DickTracy pode ser instalado em todo o PC na rede. Execute-o, e conecte-o ao endereço IP de Um ou Mais Servidores Cisco ICM NT de seu WS-X6624. Uma vez que conectado, clique a opção. Comece registrar, a seguir inscreva os comandos seguintes no campo da linha de comando: Para obter o status de porta, incorpore estados da mostra 5 (isto fornece um estado de cada porta. Com DickTracy, os números de porta são 0 baseado: A porta 1 na lâmina é a porta 0 em DickTracy). Para restaurar uma porta, entre no seguinte:
4 set kill port[x] 

!--- Where x is the 0-based port number.

5 disable port x
5 enable port x
Nenhuma monitoração disponível para a instalação do Multilink. Os enlaces serial individuais não podem ser IP permitido. A recomendação é usar o Simple Network Management Protocol (SNMP) para votar o status da interface. Há diversas maneiras de fazer isto. A opção testada é criar um script Unix para utilizar o comando snmpget recolher o status da interface a mesma maneira que o comando ping script faz. Uma outra opção é estender a função do MRTG (esta é uma ferramenta do freeware SNMP para recolher a utilização da relação) para recolher o status da interface. A opção é usar um aplicativo de gerenciamento de rede com base em SNMP.
B300309 O roteador recarrega periodicamente devido ao erro de barramento. O comportamento de manipulação de pacote anômala foi detectado em revisões adiantadas do hardware PA-2FEISL como descrito na edição CSCdm74172 da identificação de bug Cisco (clientes registrados somente). As edições foram endereçadas através de uma alteração de hardware rapidamente aos adaptadores da porta de Ethernet/ISL 2-port. Os cartões PA-2FEISL-xx com os números de revisão de hardware iguais a ou mais tarde do que as revisões de hardware alistadas abaixo não são afetados. A revisão de hardware 2.0 NB da revisão de hardware 1.2 PA-2FEISL-TX e PA-2FEISL-FX usava a revisão de hardware 1.1.
A953213 Incapaz de alcançar a página de usuário do CallManager da Cisco. Esta edição era resolved usando o seguinte procedimento.
  1. Vá à página do ccmadmin. Clique o sistema no menu principal e clique então parâmetros empresariais.
  2. Da página do parâmetro empresarial, verifique o LDAP: Cisco Base e LDAP: Parâmetros da base do usuário. (LDAP: O Cisco Base deve ser o=cisco.com e LDAP: A base do usuário deve ser ou=Users, o=cisco.com.)
Após ter atualizado estes parâmetros, todos os usuários podiam entrar da página de usuário. O problema foi encontrado no CallManager da Cisco 3.0.4 onde os parâmetros acima mencionados eram NULOS.


Informações Relacionadas


Document ID: 13968