Voz : H.323

VoIP de projeto e de distribuição sobre o ISDN

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


Índice


Introdução

A Voz sobre IP (VoIP) sobre a rede digital de serviço integrado (ISDN) é às vezes uma combinação desejável, especialmente nas redes de empreendimento usando a Telefonia IP. As características exigidas para fornecer o Qualidade de Serviço (QoS) necessário para VoIP, o Low Latency Queuing (LLQ), o Class Based Weighted Fair Queuing (CBWFQ), e o Link Fragmentation and Interleaving (LFI), são apoiadas para o ISDN e a combinação trabalha. Contudo, há umas considerações de projeto significativas a levar em consideração. Este documento discute as advertências e as limitações envolvidas em usar estas características de QoS relativas VoIP com o ISDN, e fornece algumas configurações de amostra testadas.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • ISDN

  • Point-to-Point Protocol (PPP)

  • Multilink PPP (MLPPP)

  • LFI

  • LLQ

  • CBWFQ

  • Protocolo de Tempo Real Compactado (cRTP)

Este documento não fornece o treinamento de tecnologia nestes assuntos mas um pouco uma explicação de como estas Tecnologias trabalham junto em uma rede voip. Veja a seção da “informação relacionada” para obter mais informações sobre destes assuntos.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Software Release 12.2 do½ do¿Â do Cisco IOSïÂ

  • Cisco IOS Software Release 12.2(2)T a 12.2(10)T

  • Cisco IOS Software Release 12.2(12)T e Mais Recente

Estas opções do projeto são apresentadas neste documento e foram testadas com os Cisco IOS Software Release notáveis:

Os testes foram executados usando o seguinte equipamento. Este Roteadores foi conectado diretamente através do ISDN. Pagent foi usado para simular o tráfego e o oversubscribe RTP a conexão.

  • Cisco 7200 Router com relação PRI

  • Cisco 2600 Router com interface BRI

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Problemas de desenho

Há três edições que exigem a consideração especial quando você projeta VoIP sobre redes de ISDN. Estes são descritos momentaneamente nesta tabela e expandidos então em cima.

Problema Descrição
Largura de Banda Variável A largura de banda do enlace de ISDN varia enquanto os canais B são adicionados ou deixados cair.
Requisição do pacote causada pelo LFI Quando os pacotes RTP são intercalados podem chegar fora de serviço quando transmitidos através dos canais B múltiplos.
Limitações do controle de admissão da chamada do CallManager da Cisco (CAC) O CAC baseado em localização do CallManager da Cisco não é atualmente topologia ciente.

Largura de Banda Variável

O ISDN permite que os canais B sejam adicionados ou deixados cair em resposta à procura para a largura de banda. O fato de que a largura de banda de um link varia ao longo do tempo apresenta um desafio especial aos mecanismos de filas CBWFQ e LLQ do Cisco IOS. Até o Cisco IOS Software Release 12.2(2)T, um mapa de política que executasse LLQ ou o CBWFQ poderiam somente ser atribuídos uma quantidade fixa de largura de banda. À revelia, a largura de banda atribuída pode somente consumir 75% da largura de banda disponível. Em uma interface, o CBWFQ e o LLQ supõem que somente 64 kbps estão disponíveis, mesmo que a relação tenha o potencial fornecer 1.544 ou 2.408 Mbps da largura de banda. Consequentemente, somente 75% de 64 kbps, ou de 48 kbps, pode ser atribuído por um mapa de política em toda a interface. Isto restringe o número de chamadas VoIP que podem ser levadas. Se mais largura de banda é atribuída, a seguir um Mensagem de Erro está gerado quando o mapa de política é aplicado à interface.

Considere este uso do mapa de política como um exemplo:

O comando policy-map
policy-map isdn-qos
  class VoIP-RTP
  priority 64
  class VoIP-Sig
  bandwidth 10

Quando é aplicado a uma interface BRI, o comando policy-map está rejeitado porque mais de 75% de um canal B (48 kbps) é reservado:

O comando service-policy output

!--- Note the highlighted error message when the policy 
!--- is applied to the dialer interface
.

router(config)# interface dialer 0
  router(config-if)# service-policy output isdn-qos
  I/f Dialer0 class VoIP-RTP requested bandwidth 64 (kbps) Available only 47 (kbps)

A solução a este problema foi introduzida no Cisco IOS Software Release 12.2(2)T. Até à data desta liberação, é possível reservar um porcentagem de largura de banda disponível em vez de um volume absoluto de largura de banda. A fim reservar 64 kbps para o RTP e 8 kbps para sinalizar em uma interface BRI com os dois canais B que os kbps do total 128 e um canal D de 8 kbps, a serviço-política são:

O comando policy-map
policy-map isdn-qos
  class VoIP-RTP
  priority percent 50
  class VoIP-SIG
  bandwidth 8

Em consequência, tem 32 kbps disponível para o RTP quando o primeiro canal B vem acima, e 64 kbps disponível quando o segundo canal vem acima. Além, o Cisco IOS nunca remove a serviço-política da relação devido à sobreassinatura, desde que uma sobreassinatura pode nunca ocorrer.

Requisição do pacote causada pelo LFI

Quando você executa VoIP sobre o ISDN, o MLPPP está usado para o LFI. O LFI divide grandes pacotes de dados em fragmentos menores e transmite-os paralelamente através de todos os canais B no pacote. Os pacotes de voz são intercalados ao mesmo tempo entre os fragmentos e seu atraso é reduzido. Os pacotes intercalados não são sujeitos ao encapsulamento MLPPP, eles são encapsulados como pacotes PPP regulares. Consequentemente, não têm nenhum número de sequência MLPPP e não podem ser requisitados novamente se chegarem fora de serviço. A possibilidade para requisitar novamente é real. A profundidade das várias filas do link no pacote pode diferir, que faz com que os pacotes RTP se alcancem em consequência da diferença no retardo de enfileiramento. Os vários canais B podem igualmente tomar trajetos diferentes através da rede de ISDN e terminá-los acima com retardos de transmissão diferentes.

Geralmente, esta reordenação de pacotes não é problema para pacotes RTP. Os bufferes de controle de variação de sinal nos dispositivos voip de recepção requisitam novamente os pacotes baseados nos números de sequência RTP. Contudo, a requisição transforma-se um problema se o cRTP é usado. O algoritmo cRTP supõe que os pacotes RTP são comprimidos e descomprimidos na mesma ordem. Se obtêm requisitados novamente, a seguir a descompressão não ocorre corretamente. Não é atualmente seguro usar o cRTP se há mais de um canal B no pacote MLPPP. A mesma limitação aplica-se para o MLPPP over ATM ou o Frame Relay. Neste caso, o cRTP não é possível se há mais de um virtual circuit (VC) no pacote.

Uma solução ao problema de requisição é oferecida pelo Multilink PPP da multi-classe (MCMP). O MCMP dá aos pacotes intercalados um encabeçamento pequeno com um número de sequência. Isto permite que os pacotes intercalados estejam requisitados novamente pela ponta oposta do pacote, antes que o descompactação cRTP ocorra. O apoio MCMP é esperado no Cisco IOS Software Release 12.2(12)T. Refira o RFC 2686 e a identificação de bug Cisco CSCdv46666 (clientes registrados somente) para mais informações.

Limitações de CAC do CallManager da Cisco

Os clientes de empreendimento com redes de filial usam frequentemente o ISDN para o backup de dados. Quando a Telefonia IP é distribuída, os clientes gostam de usar o link do backup de ISDN para a Voz, assim como dados. Esta configuração é possível mas há algumas advertências a observar.

A Telefonia IP nas redes de filial é baseada tipicamente no modelo centralizado do processamento de chamada, e usa o CAC baseado em localização para limitar o número de atendimentos através de WAN. O CAC baseado em localização não tem atualmente nenhum mecanismo para seguir alterações de topologia na rede. O CallManager da Cisco não está ciente se o link principal a um ramo vai para baixo e o backup de ISDN ativa. Por este motivo, é crítico que o link do backup de ISDN apoia o mesmo número de chamadas VoIP que o enlace principal. Se não, o CAC poderia oversubscribe o link de backup.

A largura de banda real do link principal e do link de backup não precisa de ser idêntica. Os links apenas precisam de poder levar o mesmo número de chamadas VoIP. Por exemplo, o link de backup pode usar o cRTP quando o link principal não fizer. Neste caso, menos largura de banda é exigida no link de backup para levar o mesmo número de atendimentos que o link principal.

Opções do projeto

Há umas várias opções de design amplo disponíveis ao projetista de rede baseado no Cisco IOS Software Release usado. Estas opções são:

A discussão em cada opção segue incluir os exemplos de configuração alistados aqui.

Voz e dados que coexistem em um único canal B com ou sem o cRTP

No Cisco IOS Software Release 12.2, a largura de banda em um mapa de política pode somente ser especificada como uma quantidade fixa até um máximo padrão de 75% da largura de banda de enlace. Além, o ISDN é suposto sempre para fornecer 64 kbps da largura de banda independentemente do número de canais B usados em uma relação BRI ou PRI. Consequentemente, 48 kbps são o máximo padrão da largura de banda que pode ser reservada no mapa de política para o ISDN.

Estas limitações significam que fazem somente o sentido usar um canal B para pacotes RTP levando. Baseado nas exigências, você pode escolher levar dados e Voz no mesmo canal B. Alternativamente, você pode usar o segundo canal B de um BRI para dados somente. Nboth of these opções do projeto, é seguro usar o cRTP como todos os pacotes RTP viajam abaixo de um único canal B, e não pode chegar fora de serviço.

Esta opção do projeto envia toda a voz e tráfego de dados abaixo de um único canal B. Desde que a Voz e os dados competem para o mesmo link, você precisa o LFI, o LLQ, e o CBWFQ. Você pode igualmente com segurança usar o cRTP desde que não há nenhuma oportunidade para pacotes RTP a se tornar requisitada novamente.

À revelia, uma serviço-política não pode reservar mais de 48 kbps (75% de 64 kbps) para o RTP e a sinalização voip. A quantidade mínima que você pode atribuir à classe da sinalização voip é 8 kbps. Com os 40 kbps permanecendo disponíveis para o uso do RTP, você pode produzir esta tabela que mostra o número máximo de atendimentos que podem ser levados por um único BRI.

Tamanho de amostra (bytes) PPS cRTP Comprimento do pacote (bytes) Largura de banda (kbps) Atendimentos pelo BRI
20 50 Não 66 26.4 1
20 50 Sim 28 11.2 3
30 33 Não 76 20.1 1
30 33 Sim 38 10.0 3
40 25 Não 86 17.2 2
40 25 Sim 48 9.6 4

Esta saída mostra uma configuração de exemplo para a Voz e os dados no mesmo canal B.

Configuração para a Voz e dados em um único canal B com cRTP

!--- This section shows only relevant parts of the configuration.


class-map match-all VoIP-RTP
 match ip dscp ef
 
!--- RTP packets.

class-map match-all VoIP-SIG
 match ip dscp af31
 
!--- VoIP signaling packets.


policy-map voice-and-data
 class VoIP-RTP
  priority 40
 
!--- 40 Kbps available for voice.

 class VoIP-SIG
  bandwidth 8
  
!--- 8 Kbps is the minimum value allowed by Cisco IOS.


interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 bandwidth 64
 
!--- Increase the bandwidth from 56 to 64 Kbps
. 
 dialer pool 1
 dialer remote-name routerB-dialer1
 dialer-group 1
 dialer string 12345678
 service-policy output voice-and-data
 
!--- The service policy.

 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 
!--- THe LFI delay equals 10 msec.

 ppp multilink interleave
 
!--- Enable LFI.

 ip rtp header-compression
 
!--- RTP header compression is OK.

Voz e dados nos canais B Separate com ou sem o cRTP

Este projeto é igualmente possível por meio do Cisco IOS Software Release 12.2. Contudo, a fim fazer o melhor uso dos canais B de ISDN disponíveis, a Voz e os dados são separados. O exemplo escolhido é apropriado para uma configuração da taxa básica onde os pacotes RTP usem um canal B, e o uso dos dados e da sinalização de voz o segundo canal B. Os conceitos similares aplicam-se para uma configuração da taxa principal onde mais canais possam ser usados para dados.

Porque os pacotes RTP não competem com nenhuns dados, o LFI e o LLQ no canal de voz não devem ser exigidos. Contudo, é uma boa prática permiti-la de qualquer maneira. O Cisco Discovery Protocol (CDP) e as atualizações de roteamento podem ser permitidos por engano, ou um ataque de recusa de serviço (DOS) pode inundar o canal de voz. No canal de dados, nenhum LFI é exigido. Mas o CBWFQ é exigido para proteger a sinalização voip dos dados gerais. As atualizações de roteamento no canal de voz precisam de ser suprimidas para evitar o tráfego que é distribuído através desta relação. Em seu lugar, use o roteamento baseado política para forçar pacotes RTP através do canal de voz. Você pode com segurança usar o cRTP desde que não há nenhuma oportunidade para pacotes RTP a se tornar requisitada novamente.

À revelia uma serviço-política não pode reservar mais de 48 kbps (75% de 64 kbps) para o RTP e a sinalização voip. Contudo, é seguro aumentar a porcentagem a 90% com este projeto, porque não há nenhum outro tráfego no canal de voz. Este máximo aumentado pode ser especificado com o comando max-reserved-bandwidth.

Baseado em 57 kbps para o RTP, você pode produzir esta tabela que mostra o número máximo de atendimentos que um único BRI pode levar.

Tamanho de amostra (bytes) PPS cRTP Comprimento do pacote (bytes) Largura de banda (kbps) Atendimentos pelo BRI
20 50 Não 66 26.4 2
20 50 Sim 28 11.2 5
30 33 Não 76 20.1 2
30 33 Sim 38 10.0 5
40 25 Não 86 17.2 3
40 25 Sim 48 9.6 5

Esta tabela mostra uma configuração de exemplo para a Voz e os dados nos canais B separados.

Configuração para a Voz e dados nos canais B Separate com cRTP

!--- This section shows only relevant parts of the configuration.



Class-map match-all VoIP-RTP
 match ip dscp ef
class-map match-all VoIP-SIG
 match ip dscp af31 

policy-map voice-only
 class VoIP-RTP
  priority 57

policy-map data-and-signaling
 class VoIP-SIG
  bandwidth 8

interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 bandwidth 64
 
!--- Increase the bandwidth from 56 to 64 Kbps.

 dialer pool 1
 dialer remote-name routerB-dialer1
 max-reserved-bandwidth 90
 
!--- Allow 90% of the bandwidth to be reserved.

 dialer-group 1
 dialer string 12345678
 service-policy output voice-only
 
!--- RTP packets only.

 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave 
 ip rtp header-compression

interface Dialer2
 encapsulation ppp
 dialer pool 1
 dialer remote-name routerB-dialer2
 dialer-group 1
 dialer string 12345678
 service-policy output data-and-signaling
 
!--- Data and VoIP signaling.

 ppp authentication chap
 ppp chap hostname routerA-dialer2
 ppp chap password cisco

router eigrp 1
 passive-interface dialer 1
 
!--- Suppress routing on the voice channel.


interface fastethernet 0/1
 ip policy route-map ip-rtp
 
!--- Policy route RTP packets.


route-map ip-rtp permit 10
 match ip address 100
 set interface dialer 1
 
!--- Route RTP packets out dialer 1.


access-list 100 permit udp any range 16384 32768
  any range 16384 32768 dscp ef

Voz e dados que coexistem nos canais B múltiplos sem cRTP

Este projeto aproveita-se do fato que até à data do Cisco IOS Software Release 12.2(2)T, você pode especificar a largura de banda no mapa de política como uma porcentagem em vez de um número absoluto. Esta capacidade permite que você aplique uma política de serviços a um pacote com canais B múltiplos. Em consequência, os pacotes RTP podem ser levados através dos canais B múltiplos. As trocas são que a aplicação dos caminhos múltiplos significa que o cRTP não é seguro usar devido à reordenação potencial dos pacotes RTP.

O Cisco IOS fornece dois mecanismos para que você controle como os canais B adicionais são trazidos em resposta à procura. O primeiro mecanismo é referido geralmente como o roteamento por encomenda do seletor (DDR). O DDR exige um limiar de carga ser especificado como uma fração da largura de banda disponível. Quando o fluxo de tráfego excede este número de limiar, um canal adicional está adicionado ao pacote. O ponto inicial está calculado porque uma média running, e lá é determinado atraso em trazer acima os canais B adicionais quando a carga aumenta. Este atraso não é um problema com dados. Contudo, com Voz, não é aceitável se um usuário faz uma chamada telefônica, e toma minutos para trazer acima a largura de banda requerida para apoiar o QoS para o atendimento.

Você pode reduzir o atraso para trazer acima os canais adicionais a ao redor 30 segundos com o comando load-interval na interface física. Contudo, mesmo 30 segundos são demasiado longos para que um atendimento vá sem o QoS exigido. A solução é ter o comando dialer load-threshold ajustado a um valor que assegure a largura de banda suficiente na reserva para apoiar pelo menos uma chamada VoIP adicional com QoS apropriado.

Desde que o problema ainda existe se dois atendimentos são trazidos acima dentro do intervalo 30-second, um segundo e uma solução mais robusta estão preferidos. A solução é trazer acima todos os canais B imediatamente e mantê-los acima enquanto o serviço de ISDN é exigido. Você pode usar o comando ppp multilink links minimum especificar esta ação.

Com os dois canais B disponíveis, a serviço-política pode agora reservar 96 kbps (75% dos kbps 128) para o RTP e a sinalização voip. Você precisa 8 kbps para a sinalização voip, assim que esta deixa 88 kbps para o RTP. Baseado no uso de dois canais B, esta tabela mostra o número máximo de atendimentos que podem ser levados no BRI.

- - -
Tamanho de amostra (bytes) PPS cRTP Comprimento do pacote (bytes) Largura de banda (kbps) Atendimentos pelo BRI
20 50 Não 66 26.4 3
20 50 Sim 28 11.2
30 33 Não 76 20.1 4
30 33 Sim 38 10.0
40 25 Não 86 17.2 5
40 25 Sim 48 9.6

Esta saída mostra uma configuração de exemplo para a Voz e os dados que coexistem nos canais B múltiplos sem cRTP.

Configuração para a Voz e dados que coexistem nos canais B múltiplos sem cRTP

!--- This section shows only relevant parts of the configuration.



Class-map match-all VoIP-RTP
 match ip dscp ef
class-map match-all VoIP-SIG
 match ip dscp af31 

policy-map voice-and-data
 class VoIP-RTP
  priority percent 65
  
!--- This is 65% of 64/128K for RTP.

 class VoIP-SIG
  bandwidth percent 10
  
!--- This is 10% of 64/128K for VoIP signaling.


interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 dialer pool 1
 dialer remote-name routerB-dialer1
 dialer-group 1
 dialer string 12345678
 service-policy output voice-and-data
 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave 
 ppp multilink links minimum 2
 
!--- Bring up two B-channels immediately.

 no ip rtp header-compression
 
!--- cRTP is not safe

Voz e dados que coexistem nos canais B múltiplos com cRTP

Com a introdução de MCMP no Cisco IOS Software Release 12.2(12)T, o cRTP que requisita novamente a edição é resolvido, e é possível ter os canais B múltiplos do uso da Voz e fazer ainda o cRTP. Os princípios do design para este são idênticos àquele discutidos na Voz e nos dados que coexistem nos canais B múltiplos sem seção do cRTP, com a única diferença que é que você pode agora permitir o cRTP. Esta tabela adiciona o número máximo de atendimentos que podem ser levados no BRI, com base no uso do cRTP em dois canais B.

Tamanho de amostra (bytes) PPS cRTP Comprimento do pacote (bytes) Largura de banda (kbps) Atendimentos pelo BRI
20 50 Não 66 26.4 3
20 50 Sim 28 11.2 7
30 33 Não 76 20.1 4
30 33 Sim 38 10.0 8
40 25 Não 86 17.2 5
40 25 Sim 48 9.6 9

Para esta encenação a configuração para a Voz e os dados que coexistem nos canais B múltiplos sem cRTP aplica-se. A exceção é que o MCMP está permitido agora e o cRTP está em quando você adiciona esta saída à interface do discador.

Configuração da multi-classe do multilink de PPP da amostra

!--- This command is available with Cisco IOS Software Release 12.2(12)T.
 
interface Dialer1 ppp multilink multiclass
	  
!--- Enable MCMP.

 ip rtp header-compression
    
!--- Support cRTP on the bundle


Informações Relacionadas


Document ID: 25610