Voz : H.323

Procesamiento de prefijos de zona con puntos versus asteriscos

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento trata sobre el problema que han experimentado algunos instaladores de red con el uso de puntos como comodines dentro de los prefijos de zona. Entonces presenta una solución general a este problema proponiendo el uso, en lo posible, del asterisco (“comodines del *") en lugar de otro. Finalmente, el presente documento clarifica la lógica de procesamiento de zona con una referencia específica a la diferencia entre los dos métodos de configuración de comodines.

prerrequisitos

Requisitos

Los Quien lea este documento deben estar bien informados de los flujos y del gatekeeper de Cisco conceptos de H.323, particularmente procesamiento de zona. Refiera comprensión del ruteo de llamadas del Cisco IOS Gatekeeper y configurar Gatekeepers H.323 y los proxys para más información sobre el gatekeeper de Cisco y el procesamiento de zona. El primer de estos documentos es útil para entender el proceso de las zonas de gatekeeper.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Problema

La causa raíz de la confusión relacionada con el uso de los puntos y de los asteriscos miente en el comportamiento predeterminado del portero mientras que procesa los prefijos. Esta conducta, descripta con detalles en la sección Explicación del comportamiento predeterminado de un control de acceso para el procesamiento prefijo de zona de este documento, puede crear situaciones ambiguas si hay una superposición en el plan de marcado y la configuración hace uso de los puntos y los asteriscos.

Los síntomas y las características del problema son:

  • Se espera que rutee las llamadas a más de una zonas locales o se espera que al control de acceso local rutee las llamadas a los porteros en las zonas remotas o ambas.

  • Las llamadas dentro de una zona local se pueden rutear exitosamente.

  • Algunos, pero no todos, las llamadas entre zonas se pueden rutear con éxito.

  • Las llamadas entre zonas que no se rutean con éxito están a los números llamados con un número específico de dígitos. Por ejemplo, las llamadas a un 10-digit o a un número del nueve-dígito pueden tener éxito, mientras que una llamada a un número de tres dígitos que comienza con el mismo dígito falla confiablemente.

  • La configuración de control de acceso hace uso de los comodines del punto dentro de los prefijos de zona.

Solución

Cuando usted especifica los dígitos comodines dentro de un prefijo de zona, evite usando los puntos en lo posible. En lugar, utilice al comodín menos específico del asterisco. Usted puede también evitar el problema cuando usted observa estas reglas:

  1. Si el plan de marcación es constante, usted puede utilizar una configuración con solamente los puntos (o usar solamente los asteriscos).

  2. Si se produce una superposición en el plan de marcado, es mejor seguir configurando con asteriscos.

  3. Si hay coincidencia en el plan de marcación, y una configuración con solamente los asteriscos no es conveniente, estudie el comportamiento predeterminado del portero de la deducción de prefijo (deduzca y prepend el código de área local) antes de que usted configure al portero.

La tercera regla requiere una comprensión de los detalles del comportamiento del portero según lo descrito en este documento.

Explicación del comportamiento predeterminado de un control de acceso para el procesamiento de prefijos de zona

Este ejemplo ilustra el comportamiento de un portero cuando procesa un pedido de llamada bajo la forma de pedido de admisión (ARQ) de un punto final de H.323. Los pasos 2 y 3 son dominantes para el alcance de este documento. Usted puede caminar a través de este organigrama más adelante en el documento con una referencia al debug del ejemplo: Una llamada fallida.

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

El procesamiento de prefijo de zona es levemente diferente que el proceso del prefijo de destino. Cuando usted hace juego los prefijos de zona, el gatekeeper de Cisco hace una tentativa especial de calificar la zona por el código de área si es posible. Si a número al que se llamó se corresponde con en las zonas locales, el portero deduce que el código de área local (el prefijo del número que llama) se debe prepended al número al que se llamó.

Por ejemplo, un ARQ entra en un gatekeeper con un número de llamada “415xxxxxxx” (con un código de área 415).

El portero tiene la zona 415 configurada como soportar el prefijo el "415......." (siete puntos). Debido a esta entrada, si número al que se llamó es 5551212 (específicamente siete dígitos) entonces el portero prepends la con el mismo prefijo que el número que llama. Por consiguiente, el número llamado a procesar es 4155551212, en la zona local.

Nota: El número de puntos en un comando zone prefix determina si un número marcado corresponde a la zona local. En el antedicho, un número del seis-dígito (por ejemplo: 555123) no hace juego con el prefijo de zona configurado del "415......." (siete puntos). Por lo tanto, número al que se llamó no se deduce para ser 415555123, sino sigue siendo 555123 y hace juego el prefijo de zona del "555*".

Sin embargo, si las zonas locales se configuran como "415*", y la configuración también incluye las zonas predeterminadas X que dirige “*”, después cuando está pedida resolver el direccionamiento 5551212, los procesos de gateway el ARQ como correspondiendo con en la zona X, si X es otra zona en el control de acceso local, o envía un Location Request (LRQ) a X si es zonas remotas.

Éste es un ejemplo que ilustra el concepto con una referencia a los fragmentos de la configuración del � del Cisco IOS que corresponden con.

Comportamiento de los prefijos de zona con puntos versus asteriscos –Fragmentos de la configuración de control de acceso

!--- 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.

Caso Práctico

Nota: Este caso práctico hace uso de un solo gatekeeper con dos zonas locales. Los mismos principios se aplican a los diseños del varios gatekeepers donde configuran al control de acceso local para remitir los LRQ a los porteros de las zonas remotas.

Este diagrama muestra una opinión simplificada de la zona de H.323 de una red del proveedor de servicios del “nuevo mundo”. Esta red provee llamadas de Voz sobre IP (VoIP) entre clientes H.323 en la zona llamada localzone2 y también acceso a la Red de telefonía pública conmutada (PSTN) desde esos mismos clientes. Las puertas de enlace troncal (TGW) que brindan acceso a la PSTN residen en una zona separada denominada localzone1.

zone_pre_process_dots_asterisks-2.gif

Nota: Los clientes de H.323 pueden ser usuarios nativos de la Telefonía IP de H.323, los dispositivos adaptadores simples analogue-to-H.323, tales como Cisco ATA u otros productos de terceros similares, o gatewayes a mayor escala. El soporte para el gateway a mayor escala diseña, determinado ésos con los usuarios remotos de telefonía, exigiría probablemente una estructura más compleja de la zona que lo que se discute en este caso estudia. Además, los 5350 TGW pueden proporcionar el acceso PSTN a través de las conexiones digitales E1/T1 tales como Primary Rate ISDN o Señalización asociada al canal (CAS). También pueden proporcionar la interconexión directa SS7 con el uso de un agente conveniente de la llamada SS7, tal como Cisco SC2000 o PGW2200.

Comandos configuration y show

Muestran los comandos gatekeeper-related instalados en el portero aquí. Las líneas en la configuración se resaltan que son significativas en más adelante la demostración del problema con, en este caso, los números de teléfono tridigitales donde una llamada se intenta de localzone2 al localzone1.

Configuración de control de acceso (comandos gatekeeper solamente)
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 salida del comando show gatekeeper endpoints muestra los puntos finales de H.323 registradoes con el portero junto con las zonas en las cuales se registran.

Nota: Los TGW se han registrado correctamente al portero en el localzone1 mientras que los Terminales H.323 se registran en 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 hecho salir correctamente indica la zona a la cual los prefijos respectivos E.164 deben ser ruteados.

muestre el prefijo de las zonas 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 salida del comando show gatekeeper gw-type-prefix muestra los prefijos de la tecnología configurados para este portero.

Note que solamente el tecnología-prefijo predeterminado (1#) está configurado en el portero. Además, sólo las TGW 5350 (tg1 y tgw2) en la zona localzone1 se configuran para que se puedan registrar con este prefijo de tecnología predeterminado.

muestre el GW-tipo-prefijo del portero
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)

Depuraciones y análisis detallado

Ésta es salida de los debugs del portero para quien muestra los flujos y el procesamiento de prefijo de zona del protocolo de registración, admisión y estado (RAS):

Incluye un comentario detallado que explica el comportamiento de la puerta de enlace al procesar comodines de punto en los prefijos de zona en comparación con los comodines de asterisco.

debug h225 y debug gatekeeper main 10 llamada fallida
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
    }

Este debug es un extracto de la salida del comando debug gatekeeper main 10 y muestra una llamada satisfactoria.

gatekeeper main 10 del debug – llamada satisfactoria
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

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 23900