Voix : H.323

Traitement des préfixes de zone avec les points et les astérisques

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document discute un problème que quelques responsables de l'implémentation de réseau ont rencontré avec l'utilisation des points comme masques dans des zones prefix. Il présente alors une solution au problème générale en proposant l'utilisation, dans la mesure du possible, des masques de ("*")d'astérisque à la place. En conclusion, ce document clarifie la zone traitant la logique avec une référence spécifique à la différence entre les deux méthodes de configurer des masques.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient être bien informés H.323 des concepts d'écoulements et de garde-porte de Cisco, en particulier traitement de zone. Référez-vous compréhension derrière le routage d'appels de garde-porte de Cisco IOS et configurer des Contrôleurs d'accès H.323 et des proxys pour plus d'informations sur le traitement de garde-porte et de zone de Cisco. Le premier de ces documents est utile pour comprendre le traitement de zone de garde-porte.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

La cause principale de la confusion liée à l'utilisation des points et des astérisques se situe dans le comportement par défaut du garde-porte tout en traitant des préfixes. Ce comportement, décrit en détail dans l'explication de la section de comportement de traitement de zone prefix de par défaut de garde-porte de ce document, peut créer des situations ambiguës s'il y a une superposition dans le Plan de composition et la configuration se sert des points et des astérisques.

Les symptômes et les caractéristiques du problème sont :

  • On s'attend à ce que conduise des appels à plus d'une zone locale ou on s'attend à ce que le contrôleur d'accès local conduise des appels aux garde-portes dans des zones distantes ou chacun des deux.

  • Des appels dans une zone locale peuvent être conduits avec succès.

  • Certains, mais pas tous, des appels d'interzone peuvent être conduits avec succès.

  • Les appels d'interzone qui ne sont pas conduits avec succès sont aux numéros appelés avec un nombre spécifique de chiffres. Par exemple, les appels à un 10-digit ou à un nombre de neuf-chiffre peuvent réussir, alors qu'un appel à un nombre de trois chiffres commençant par le même chiffre échoue sûrement.

  • La configuration du contrôleur d'accès se sert des masques de point dans des zones prefix.

Solution

Quand vous spécifiez des chiffres de masque dans une zone prefix, évitez utilisant des points si possible. Au lieu de cela, utilisez le masque d'astérisque de moins-particularité. Vous pouvez également éviter le problème quand vous observez ces règles :

  1. Si le Plan de composition est cohérent, vous pouvez utiliser une configuration avec seulement des points (ou utiliser seulement des astérisques).

  2. S'il y a une superposition dans le Plan de composition, il est le meilleur de coller à utiliser des configurations avec des astérisques.

  3. S'il y a superposition dans le Plan de composition, et une configuration avec seulement des astérisques n'est pas appropriée, étudiez le comportement par défaut du garde-porte de deviner de préfixe (déduisez et ajoutez le code au début local) avant que vous configuriez le garde-porte.

La troisième règle exige une compréhension des détails du comportement du garde-porte comme décrit dans ce document.

Explication du comportement de traitement de zone prefix de par défaut de garde-porte

Cet exemple montre le comportement d'un garde-porte quand il traite une demande d'appel sous forme de demande d'admission (ARQ) H.323 d'un point final. Étapes 2 et 3 sont principales pour la portée de ce document. Vous pouvez faire un pas par cet organigramme plus tard dans le document avec une référence à l'exemple mettez au point : Un appel défaillant.

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

Le traitement de zone prefix est légèrement différent que le traitement de préfixe de destination. Quand vous appariez des zones prefix, le garde-porte de Cisco fait une tentative spéciale de qualifier la zone par code postal si possible. Si un numéro appelé est apparié dans la zone locale, le garde-porte déduit que le code local (le préfixe du numéro d'appel) devrait être ajouté au début au numéro appelé.

Par exemple, un ARQ entre dans un garde-porte avec l'appel le numéro "415xxxxxxx" (avec code postal 415).

Le garde-porte a la zone 415 configurée en tant que prendre en charge le préfixe "415......." (sept points). En raison de cette entrée, si le numéro appelé est 5551212 (spécifiquement sept chiffres) puis le garde-porte l'ajoute au début avec le même préfixe que le numéro d'appel. Par conséquent, le numéro appelé à traiter est 4155551212, dans la zone locale.

Remarque: Le nombre de points dans une commande de zone prefix détermine si un numéro appelé s'assortit dans la zone locale. Dans ce qui précède, un nombre de six-chiffre (par exemple : 555123) ne s'assortit pas avec la zone prefix configurée de "415......." (sept points). Par conséquent, le numéro appelé n'est pas déduit pour être 415555123, mais reste 555123 et apparie la zone prefix de "555*".

Cependant, si la zone locale est configurée en tant que "415*", et la configuration inclut également une zone par défaut X qui manipule « * », puis une fois demandée à résoudre l'adresse 5551212, la passerelle traite l'ARQ comme appariant dans la zone X, si X est une autre zone sur le contrôleur d'accès local, ou envoie une demande d'emplacement (LRQ) à X si c'est une zone distante.

C'est un exemple qui montre le concept avec une référence aux extraits assortis de configuration de½ du¿Â du Cisco IOSïÂ.

Comportement de zone prefix avec des points contre des astérisques ? Extraits de configuration du contrôleur d'accès

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

Étude de cas

Remarque: Cette étude de cas se sert d'un garde-porte simple avec deux zones locales. Les mêmes principes s'appliquent à de plusieurs conceptions de garde-porte où le contrôleur d'accès local est configuré pour expédier LRQs aux garde-portes distants de zone.

Ce diagramme affiche H.323 simplifiée une vue de zone d'un réseau du fournisseur de service du « nouveau monde ». Ce réseau permet d'accéder des appels de la voix sur ip (VoIP) entre H.323 les clients dans la zone appelée le localzone2, et également au réseau téléphonique public commuté (PSTN) de ces mêmes clients. Les passerelles de jonction (TGW) qui permettent d'accéder au PSTN résident dans une zone distincte appelée le localzone1.

zone_pre_process_dots_asterisks-2.gif

Remarque: H.323 les clients peuvent être H.323 les utilisateurs indigènes de Téléphonie sur IP, les périphériques simples de l'adaptateur analogue-to-H.323, tels que Cisco ATA ou d'autres produits tiers semblables, ou des passerelles à grande échelle. Le soutien de la passerelle à grande échelle conçoit, en particulier ceux avec les utilisateurs distants de téléphonie, vraisemblablement nécessiterait une structure plus complexe de zone que ce qui est discuté dans ce cas étudie. En outre, les 5350 TGW peuvent fournir l'accès PSTN par les connexions E1/T1 numériques telles que le débit primaire le RNIS ou le signalisation CAS (Channel Associated Signaling). Ils peuvent également fournir à l'interconnexion SS7 directe l'utilisation d'un agent approprié de l'appel SS7, tel que Cisco SC2000 ou PGW2200.

configuration et commandes show

Les commandes garde-porte garde-porte installées sur le garde-porte sont affichées ici. Les lignes dans la configuration qui sont mises en valeur sont significatives en expliquant plus tard le problème avec, dans ce cas, les numéros de téléphone de trois chiffres où un appel est tenté de localzone2 à localzone1.

Configuration du contrôleur d'accès (ordres de garde-porte seulement)
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

Cette sortie de commande de show gatekeeper endpoints affiche H.323 les points finaux inscrits au garde-porte avec les zones dans lesquelles ils sont enregistrés.

Remarque: Les TGW se sont enregistrés correctement au garde-porte dans localzone1 tandis que les Terminaux H.323 sont enregistrés dans 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

Cette sortie de commande de show gatekeeper zone prefix indique correctement la zone à laquelle les préfixes E.164 respectifs doivent être conduits.

show gatekeeper zone prefix
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*

Cette sortie de commande de show gatekeeper gw-type-prefix affiche les préfixes de tech configurés pour ce garde-porte.

Notez que seulement le tech-prefix par défaut (1#) est configuré sur le garde-porte. Supplémentaire, seulement les 5350 TGW (tg1 et tgw2) dans la zone localzone1 sont configurés pour s'inscrire à ce préfixe par défaut de technologie.

show gatekeeper gw-type-prefix
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)

Debugs et analyse détaillée

C'est sortie de débogage du garde-porte pour lequel affiche l'enregistrement, admission, et des écoulements et zone prefix de Protocol d'état (RAS) traitant :

Il inclut un commentaire détaillé qui explique le comportement du garde-porte en traitant des masques de point dans les zones prefix par rapport aux masques d'astérisque.

le debug h225 asn1 et mettent au point la canalisation 10 de garde-porte ? appel défaillant
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
    }

Ceci mettent au point est un extrait de la sortie de la commande de la canalisation 10 de garde-porte de débogage et affiche un appel réussi.

mettez au point la canalisation 10 de garde-porte ? appel réussi
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


Informations connexes


Document ID: 23900