Voz : H.323

Processamento de prefixo de zona com Pontos x Asteriscos

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


Índice


Introdução

Este documento discute um problema que alguns implementadores de rede enfrentam com o uso de pontos como curingas dentro de prefixos de zonas. Apresenta então uma solução geral a este problema propondo o uso, sempre que seja possível, do asterisco (do “convites *") pelo contrário. Finalmente, esse documento esclarece a lógica de processamento de zona com uma referência específica para a diferença entre os dois métodos de configuração de caracteres curinga.

Pré-requisitos

Requisitos

Os leitores deste documento devem ser conhecedors de fluxos de H.323 e de conceitos do gatekeeper Cisco, em particular processamento de zona. Refira compreensão do roteamento de chamada do Gatekeeper e configurar-lo H.323 gatekeepers e proxys para obter mais informações sobre do gatekeeper Cisco e do processamento de zona. O primeiro destes documentos é útil para compreender o processamento da zona de gatekeeper.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

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

Problema

A causa de raiz da confusão relativa ao uso dos pontos e dos asteriscos encontra-se no comportamento padrão do porteiro ao processar prefixos. Esse comportamento, descrito em detalhes na seção Explanation of Gatekeeper Default Zone Prefix Processing Behavior deste documento, pode criar situações ambíguas se houver uma sobreposição no plano de discagem e a configuração usar tanto pontos como asteriscos.

Estes são os sintomas e as características do problema:

  • O gatekeeper local é esperado distribuir atendimentos a mais de uma zona local ou esperado distribuir atendimentos aos porteiros nas zonas remotas ou em ambas.

  • Chamadas em uma zona local podem ser roteadas com êxito.

  • Alguns, mas não todos, chamadas entre-zona podem ser distribuídos com sucesso.

  • As chamadas entre-zona que não são distribuídas com sucesso são aos números chamados com um número específico de dígitos. Por exemplo, os atendimentos a um 10-digit ou a um número do nove-dígito podem suceder, quando um atendimento a um número com três dígitos que começa com o mesmo dígito falhar confiantemente.

  • A configuração de gatekeeper utiliza convites do ponto dentro dos prefixos de zona.

Solução

Quando você especifica dígitos de wildcard dentro de um prefixo de zona, evite usar pontos sempre que seja possível. Em lugar de, use o convite do asterisco do menos específica. Você pode igualmente evitar o problema quando você observa estas regras:

  1. Se o dial plan é consistente, você pode usar uma configuração com somente os pontos (ou a utilização somente de asteriscos).

  2. Se houver uma sobreposição do plano de discagem, o melhor é limitá-lo, utilizando configurações com asteriscos.

  3. Se há uma sobreposição no dial plan, e uma configuração com somente asteriscos não é apropriada, estude o comportamento padrão do porteiro da suposição de prefixo (deduza e prepend o código de área local) antes que você configure o porteiro.

A terceira regra exige uma compreensão dos detalhes do comportamento do porteiro como descrito neste documento.

Explicação do comportamento de processamento de prefixo de zona padrão do gatekeeper

Este exemplo ilustra o comportamento de um porteiro quando processa um pedido de chamada sob a forma de um pedido de admissão (ARQ) de um valor-limite de H.323. Etapas 2 e 3 são chaves para o espaço deste documento. Você pode pisar através deste fluxograma mais tarde no documento com uma referência ao exemplo debuga: Uma chamada com falha.

/image/gif/paws/23900/zone_pre_process_dots_asterisks-1.gif

O processamento de prefixo de zona é levemente diferente do que o processamento do prefixo de destino. Quando você combina prefixos de zona, o gatekeeper Cisco faz uma tentativa especial de qualificar a zona pelo código de área se possível. Se um número chamado é combinado na zona local, o porteiro deduz que o código de área local (o prefixo do número chamado) deve ser prepended ao número chamado.

Por exemplo, um ARQ com destino a um gatekeeper com o número de chamada "415xxxxxxx" (com código de área 415).

O porteiro tem a zona 415 configurada como o prefixo de apoio "415......." (sete pontos). Devido a esta entrada, se o número chamado é 5551212 (especificamente sete dígitos) então o porteiro prepends o com mesmo prefixo que o número chamado. Portanto, o número chamado a ser processado é 4155551212, na área local.

Nota: O número de pontos em um comando de prefixo de zona determina se o número chamado corresponde à zona local. No acima, um número do seis-dígito (por exemplo: 555123) não combinam com o prefixo de zona configurado de "415......." (sete pontos). Consequentemente, o número chamado não é deduzido para ser 415555123, mas permanece 555123 e combina o prefixo de zona de "555*".

Contudo, se a zona local é configurada como "415*", e a configuração igualmente inclui uma zona padrão X que segure “*”, a seguir quando pedida para resolver o endereço 5551212, os processos de gateway o ARQ como combinando na zona X, se X é uma outra zona no gatekeeper local, ou envie um Location Request (LRQ) a X se é uma zona remota.

Este é um exemplo que ilustre o conceito com uma referência aos snippet de configuração de harmonização do � do Cisco IOS.

Comportamento do prefixo de zona com os pontos contra asteriscos – Snippet da configuração de gatekeeper

!--- 5551212 is the called number 
!--- and the request comes into zone localzone2.
!--- It is important to know that the calling number has prefix 415.  

zone prefix localzone2 415.......
zone prefix localzone1 555*

!--- In this case, this line is what the match is with.

Zone prefix localzone2 415.......

!--- The match is due to these reasons:


!--- 1. The calling number begins with 415.
!--- 2. There is a local wildcard entry for 415 with seven dots. This entry
!--- causes the gatekeeper to assume that the the seven-digit called
!--- number is local and therefore expands 5551212 to 4155551212 by 
!--- prepending the area code of the calling number. This expanded
!--- number matches, and the call will be accepted or rejected based on
!--- the registered resources, in localzone2.


!--- If the configuration is changed, as shown here, then there is no
!--- expansion of the number (because there is no seven-dot entry). 

zone prefix localzone2 415*
zone prefix localzone1 555*

!---  This line is what the match is now with.

Zone prefix localzone1 555* 

!--- In this case, the call is accepted or rejected based on registered
!--- resources in localzone1.

Casos Práticos

Nota: Estes Casos Práticos utilizam um gatekeeper único com duas zonas local. Os mesmos princípios aplicam-se aos projetos dos vários gatekeepers onde o gatekeeper local é configurado para enviar LRQ aos porteiros da zona remota.

Este diagrama mostra uma ideia simplificada da zona de H.323 “de uma rede de provedor de serviços do mundo novo”. Esta rede fornece chamadas de Voz sobre IP (VoIP) entre clientes H.323 na zona chamada localzone2 e também acessa a Rede de telefonia comutada pública E1 (PSTN) a partir desses mesmos clientes. Os Gateways de Entroncamento (TGWs) que fornecem acesso à PSTN residem em uma zona separada chamada localzone1.

zone_pre_process_dots_asterisks-2.gif

Nota: Os clientes de H.323 podem ser usuários nativos da Telefonia IP de H.323, dispositivos simples do adaptador analogue-to-H.323, tais como Cisco ATA ou outros produtos de terceira parte similares, ou gateways em maior escala. O apoio para o gateway em maior escala projeta, particularmente aqueles com usuários de telefonia remotas, provavelmente envolveria uma estrutura mais complexa da zona do que o que é discutido neste caso estuda. Além, os 5350 TGW podem fornecer o acesso PSTN através das conexões E1/T1 digitais tais como o Primary Rate ISDN ou a sinalização associada a canal (CAS). Igualmente podem fornecer a interconexão SS7 direta o uso de um agente apropriado do atendimento SS7, tal como Cisco SC2000 ou PGW2200.

Comandos configuration e show

Os comandos gatekeeper-related instalados no porteiro são mostrados aqui. As linhas na configuração que são destacadas são significativas mais tarde em demonstrar o problema com, neste caso, os números de telefone de três números onde um atendimento é tentado de localzone2 à zona local 1.

Configuração de gatekeeper (comandos gatekeeper somente)
gatekeeper
  zone local localzone1 dns.au 10.1.1.228
  zone local localzone2 dns.au
  no zone subnet localzone1 default enable
  zone subnet localzone1 10.1.1.240/28 enable
  no zone subnet localzone2 default enable
  zone subnet localzone2 10.99.0.0/16 enable
  zone prefix localzone1 0*
  zone prefix localzone1 1*
  zone prefix localzone1 6*
  zone prefix localzone1 8*
  zone prefix localzone2 9999931..
  Zone prefix localzone2 9999932..
  Zone prefix localzone2 9999933..
  Zone prefix localzone2 9999934..
  Zone prefix localzone2 9999935..
  Zone prefix localzone2 9999936..
  Zone prefix localzone2 9999937..
  Zone prefix localzone2 9999938..
  Zone prefix localzone2 9999939..
  Zone prefix localzone2 999994...
  zone prefix localzone2 999995...
  zone prefix localzone1 9*
  accounting vsa
  gw-type-prefix 1#* default-technology
  arq reject-unknown-prefix
  lrq reject-unknown-prefix
  no use-proxy localzone2 default inbound-to terminal
  no use-proxy localzone2 default outbound-from terminal
  no shutdown
  endpoint ttl 60

Esta saída do comando show gatekeeper endpoints mostra os valores-limite de H.323 registrados com o porteiro junto com as zonas em que são registrados.

Nota: Os TGW registraram-se corretamente ao porteiro na zona local 1 quando os Terminais H.323 forem registrados em localzone2.

show gatekeeper endpoints
GK#show gatekeeper endpoints 
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name     Type Flags
--------------- ----- --------------- ----- ---------     ---- -----
10.99.0.10      1720  10.99.0.10      45690 localzone2    TERM E164-ID: 999995988
10.99.0.11      1720  10.99.0.11      29249 localzone2    TERM E164-ID: 999995981
10.99.0.12      1720  10.99.0.12      19227 localzone2    TERM E164-ID: 999995985
10.99.0.15      1720  10.99.0.15      36889 localzone2    TERM E164-ID: 999995989
10.99.0.16      1720  10.99.0.16      42366 localzone2    TERM E164-ID: 999995982
10.99.0.18      1720  10.99.0.18      18300 localzone2    TERM E164-ID: 999995986
10.99.0.19      1720  10.99.0.19      32345 localzone2    TERM E164-ID: 999995980
10.99.0.20      1720  10.99.0.20      23155 localzone2    TERM E164-ID: 999995984
10.1.1.240      1720  10.1.1.240      50737 localzone1    VOIP-GW H323-ID: tgw1@dns.au
10.1.1.241      1720  10.1.1.241      50737 localzone1    VOIP-GW H323-ID: tgw2@dna.au
Total number of active registrations = 10

Este comando show gatekeeper zone prefix output corretamente indica a zona a que os prefixos E.164 respectivos devem ser distribuída.

mostre o prefixo da zona de gatekeeper
ZRZ-GK1#show gatekeeper zone prefix
	    ZONE PREFIX TABLE
            =================
GK-NAME               E164-PREFIX
-------               -----------
localzone1            0*
localzone1            1*
localzone1            6*
localzone1            8*
localzone2            9999931..
localzone2            9999932..
localzone2            9999933..
localzone2            9999934..
localzone2            9999935..
localzone2            9999936..
localzone2            9999937..
localzone2            9999938..
localzone2            9999939..
localzone2            999994...
localzone2            999995...
localzone1            9*

Esta saída do comando show gatekeeper gw-type-prefix mostra os prefixos da tecnologia configurados para este porteiro.

Observe que somente o tecnologia-prefixo do padrão (1#) está configurado no porteiro. Além disso, somente os 5350 TGWs (tg1 e tgw2) na zona localzone1 são configurados para registro com esse prefixo de tecnologia.

mostre o GW-tipo-prefixo do porteiro
GK#show gatekeeper gw-type-prefix 
GATEWAY TYPE PREFIX TABLE
=========================
Prefix: 1#*    (Default gateway-technology)
  Zone localzone1 master gateway list:
    10.1.1.240:1720 tgw1 
    10.1.1.241:1720 tgw2 (out-of-resources)

Depurações e discussão detalhada

Este é resultado do debug do porteiro que mostra fluxos e processamento de prefixo de zona do Registro, Admissão e Protocolo de Status (RAS) para:

Inclui um comentário detalhado que explica o comportamento do gatekeeper ao processar caracteres gerais de ponto em prefixos de zona em contraste com caracteres gerais de asterisco.

debug h225 asn1 e debug gatekeeper main 10–chamada com falha
GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!--- This output is from the debug h225 ans1 command issued on the gatekeeper. It shows 
!--- an incoming RAS ARQ for called number 112. It is important to
!--- note that the calling number (source endpoint) comes from the zone localzone2 and,
!--- assuming three-digit numbers, its prefix (source endpoint prefix) is 999995.
  
Mar 11 21:48:15: RAS INCOMING PDU ::=

value RasMessage ::= admissionRequest : 
    {
      requestSeqNum 36784
      callType pointToPoint : NULL
      callModel gatekeeperRouted : NULL
      endpointIdentifier {"618FED9800000008"}
      destinationInfo 
      {
        e164 : "112",
        e164 : "112"
      }
      srcInfo 
      {
        h323-ID : {"999995985"},
        e164 : "999995985"
      }
      srcCallSignalAddress ipAddress : 
      {
        ip '0A14000C'H
        port 11309
      }
      bandWidth 1280
      callReferenceValue 31633
      conferenceID '5634343434EF21002B211E5226E91D26'H
      activeMC FALSE
      answerCall FALSE
      canMapAlias FALSE
      callIdentifier 
      {
        guid '5634343434EF20002B211E5226E91D26'H
      }
      gatekeeperIdentifier {"localzone2"}
      willSupplyUUIEs FALSE
    }

!--- This output is from the debug gatekeeper main 10 command 
!--- issued on the gatekeeper. It 
!--- shows the gatekeeper zone prefix processing logic (rassrv_get_addrinfo). 
!--- Comments are inserted throughout. 

Mar 11 21:48:15: gk_rassrv_arq: arqp=0x61A09EE4, crv=0x7B91, answerCall=0
Mar 11 21:48:15: ARQ Didn't use GK_AAA_PROC

!--- Tech-prefix matching occurs first. In this case study, no
!--- tech-prefixes are configured so no match is found. 

Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.

!--- The next line in the trace is the key to what, in this case study, is unexpected 
!--- behavior. The expected behavior is for 112 to match with the wildcard "1*" entry 
!--- in localzone1. 

!--- The local (source) zone of the calling number is localzone2. 
!--- It has been configured as 
!--- supporting the prefix "999995..." with three wildcard digits. 
!--- (Note the configuration line 
!--- "zone prefix localzone2 999995...".)

!--- The gatekeeper, when asked to resolve a three-digit number 112, 
!--- deduces this to mean "999995-112" in the local zone because 
!--- "112" matches with the specific-length three-dot 
!--- wildcard configuration for the local zone. 

!--- This behavior is exactly the same as a local area code being assumed when a local 
!--- call is made. 



!--- If the configuration line "zone prefix localzone2 999995..." was removed from the 
!--- configuration, or if the line "zone prefix localzone2 999995*" was inserted instead,
!--- then the three-digit number "112" would not match in the local 
!--- zone but would rather match localzone1 through the 
!--- configuration line "zone prefix localzone1 1*".

Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint's zone prefix 999995

Mar 11 21:48:15: No tech-prefix

Mar 11 21:48:15: Alias not found

!--- The gatekeeper attempts to find a default technology prefix, But although "#1" is 
!--- configured, the H.323 endpoints in localzone2 correctly do not register with that. The
!--- conclusion drawn is that there is an "unknown address and no default 
!--- technology defined":

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0x805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint's zone prefix 999995
Mar 11 21:48:15: No tech prefix

Mar 11 21:48:15: Alias not found

!--- The gatekeeper indicates that it has failed to find a registered match for the  
!--- called number in localzone2:

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0x805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: gk_rassrv_sep_arq(): rassrv_get_addrinfo() failed (return code = 0x103)

!--- The gatekeeper sends the Admission Reject (ARJ) because the called party is not 
!--- registered:

Mar 11 21:48:15: RAS OUTGOING PDU ::=

value RasMessage ::= admissionReject : 
    {
      requestSeqNum 36784
      rejectReason calledPartyNotRegistered : NULL
    }

Isto debuga é um extrato da saída do comando debug gatekeeper main 10 e mostra uma chamada bem sucedida.

debugar o gatekeeper principal 10 – chamada bem sucedida
GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!--- The four-digit called number 1003 does not match with the three-dot wildcard 
!--- for localzone2 noted earlier. Instead, it matches with the less-specific 
!--- asterisk wildcard for localzone1.

Feb 19 16:52:19: rassrv_get_addrinfo(1003): Tech-prefix match failed.
Feb 19 16:52:19: rassrv_get_addrinfo(1003): Matched zone prefix 1 and remainder 003
Feb 19 16:52:19: No tech prefix
Feb 19 16:52:19: Alias not found

!--- The gatekeeper finds a default technology prefix (of #1) since the 5350
!--- TGWs register with this prefix as per the 
show gatekeeper gw-type-prefix
 command.

Feb 19 16:52:19: Technology GW selected

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 23900