Transparence ISUP du descripteur de transparence générique du commutateur logiciel PGW 2200

Introduction

Ce document fournit des détails sur la configuration de la transparence ISUP GTD (Generic Transparency Descriptor). Il explique également les éléments de configuration et de dépannage du mécanisme de transport transparent pour que le Cisco PGW 2200 transfère les informations ISUP.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants :

• Logiciel Cisco Media Gateway Controller version 9

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Logiciel Cisco PGW 2200, versions 9.3(2) et 9.4(1)

• Logiciel Cisco IOS® version 12.3 ou 12.3T

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Descripteur de transparence générique

ISUP Transparency permet de transférer des messages et des éléments d'information ISUP d'un Cisco PGW 2200 (SG1) d'entrée sur un réseau IP vers un Cisco PGW 2200 (SG2) de sortie où les messages ISUP sont reconditionnés et envoyés au réseau PSTN/SS7. Cette fonctionnalité est importante car elle permet le transport des appels depuis le réseau RTPC via un réseau IP vers un réseau RTPC sans perte d'informations de signalisation. La transparence de l'ISUP est obtenue grâce à l'utilisation du mécanisme GTD de Cisco. GTD fournit un moyen de spécifier les messages des différents protocoles utilisés dans le réseau RTPC en texte brut. Ils peuvent ainsi être facilement compris par les éléments du réseau au sein du réseau IP ou se trouver à la frontière entre le RTPC et le réseau IP.

Remarque : Si un SS7 chevauche le message d'adresse suivant (SAM) est utilisé sur SG1 (Figure 1), le NI2+ est limité à l'utilisation d'Enbloc uniquement et non à l'envoi de chevauchement. Ceci est dû aux spécifications de NI2+. Cela signifie que si la liaison SS7 sur SS7 reçoit un message d'adresse initiale SS7 (IAM) suivi par SAM, le SG2 terminé transmet les informations sur la liaison SS7 en tant qu'Enbloc, ou un message IAM.

NI2+ fait partie de Bell_1268, Telcordia Technologies Technical Reference TR-NWT-001268 Issue 1, décembre 1991. À la page 23/434, cette référence technique explique que les procédures et les états associés à l'envoi de chevauchement ne sont pas pris en charge. Seul Enbloc est pris en charge pour cette solution. Le GTD comble les lacunes pour transporter les données, mais ne remplace aucune des implémentations interactives. S'il y a des problèmes où le mappage d'interfonctionnement diffère des informations transportées par GTD, le protocole natif doit remplacer GTD.

Configurer GTD sur PGW 2200

Procédez comme suit :

1. Créez les informations GTD sur le PGW 2200.

   demask mml>prov-sta::srcver="active",dstver="gtd2"
      MGC-01 - Media Gateway Controller 2004-05-17 12:16:08.470 MET
   M  COMPLD
      "PROV-STA"
      ;
   demask mml>prov-add:gtdparam:name="ISUP",gtdparamstring="All"
      MGC-01 - Media Gateway Controller 2004-05-17 12:16:18.438 MET
   M  COMPLD
      "gtdparam"
      ;

   Remarque : Si vous activez GTD sur votre système, ces codes de paramètres ISUP sont toujours autorisés, indépendamment de vos sélections individuelles :

   • Informations sur l'événement (EVI)

   • Informations de compatibilité de champ connues (FDC)

   • Identification globale des appels (GCI)

   • Informations de compatibilité des messages (MCI)

   • Informations de compatibilité des paramètres (PCI)

   • Nom du protocole (PRN)

   Par exemple, pour modifier un jeu de paramètres GTD pour prendre en charge tous les paramètres GTD, entrez cette commande :

    mml>prov-add:gtdparam:name="ISUP",gtdparamstring="ALL"
   

   Dans un autre exemple, entrez cette commande pour modifier un jeu de paramètres GTD pour prendre en charge certains paramètres GTD :

   mml>prov-ed:gtdparam:name="ISUP", gtdparamstring="BCI, CPC, 
                     CGN, CIC, CPN, MCR"
   
    
   demask mml> prov-add:sigsvcprop:name="signas1",gtdcaptypeprop="ISUP"
      MGC-01 - Media Gateway Controller 2004-05-17 12:16:31.402 MET
   M  COMPLD
      "sigsvcprop:
       WARNING: Restart may be needed based on the property(s) added/modified.
       Refer to MGC Provisioning Guide."
      ;
   demask mml> prov-add:sigsvcprop:name="ss7path",IsupTransparencyDisabled="0"
      MGC-01 - Media Gateway Controller 2004-05-28 11:32:14.557 MET
   M COMPLD
      "sigsvcprop:
       WARNING: Restart may be needed based on the property(s) added/modified.
       Refer to MGC Provisioning Guide."   
   ;
   demask mml> prov-cpy
      MGC-01 - Media Gateway Controller 2004-05-17 12:16:52.642
    MET
   M  COMPLD
      "PROV-CPY"
      ;demask mml>

   Vous devez redémarrer si vous avez modifié ou modifié des valeurs de propriété pour que les modifications prennent effet. Voir le tableau 4-4 de la documentation MML Basics pour plus d'informations.

2. Vérifiez la configuration GTD sur le PGW 2200.

   Note : Les éléments en gras sont des éléments importants associés à GTD dans la commande MML provrtrv:gtdparam:name=« isup ».

   demask mml> prov-rtrv:gtdparam:name="isup"
      MGC-01 - Media Gateway Controller 2004-05-17 12:17:30.914 MET
   M  RTRV
      "session=gtd2:gtdparam"
      /*
    NAME = isupDESC = notSet
   GTDPARAMSTRING = ALL
   OVERRIDESTRING = NONE
      */
      ;
   
   !--- Check the profile to the Network Access Server (NAS) !--- Redundant Link Manager (RLM) group (NASPATH).
   
   demask mml> prov-rtrv:sigsvcprop:name="signas1"
      MGC-01 - Media Gateway Controller 2004-05-17 12:21:30.549
    MET
   M  RTRV
      "session=gtd2:sigsvcprop"
      /*
    ADigitCCPrefix = 0
    AInternationalPrefix = NULL
    ANationalPrefix = NULL
    BcInitState = OOS
    BDigitCCPrefix = 0
    BDigitCCrm = NULL
    BInternationalPrefix = NULL
    BNationalPrefix = NULL
    BothwayWorking = 1
    CCOrigin = NULL
    CGBA2 = 0
    CLIPEss = 0
    CompressionType = 1
    CorrelationCallIDFormat = 0
    CotInTone = 2010
    CotOutTone = 2010
   <Press 'SPACE' for next page, 'Enter' for next line or 
   'q' to quit this output>
   CotPercentage = 0
   ExtCOT = Loop
   FastConnect = 0
   

   Figure 2 : Informations de propriété FastConnect

   

   Figure 3 : Exemple pour FastConnect = 0

   

   • FastConnect - Valeur par défaut qui mappe localement la 'procédure d'appel' significative au message ACM (Address Complete Message). Ce mappage local empêche le mappage transparent de l'ACM de sortie sur le côté d'entrée. Le GTD intégré dans l'ACM de sortie arrive plus tard lorsque l'ACM d'entrée a déjà été envoyé

   • FastConnect = 1 - Ceci empêche les messages 'call-Procedure' de NI2+ générés localement (sans informations GTD) de déclencher l'ACM SS7. L'ACM d'entrée est déclenché par l'ACM de sortie et contient toutes les informations GTD. Il s'agit de la valeur recommandée lorsque GTD est activé. Voir l'ID de bogue Cisco CSCdx23349 (clients enregistrés uniquement).

     ForwardCLIinIAM = 1
     ForwardSegmentedNEED = 1
     GLARE = 0
     GRA2 = 0
     GtdCapTypeProp = ISUP
     GtdMsgFmt = c
     
     !--- GtdMsgFmt can be ‘c’ (compact) or ‘v’ (verbose).
     
     

   • IsupTransEarlyACMEnable = 0 Voir l'ID de bogue Cisco CSCea87770 (clients enregistrés uniquement). Ceci ajoute la propriété NASPATH IsupTransEarlyACMEnable (par Q.699 et H.246) où ACM ne mappe à rien (pas de progression ou d'alerte). Dans ce cas, la transparence ISUP est perdue.

     Ceci se produit lorsque ces paramètres sont définis dans l'identificateur de pont de l'ACM :

     • Statut de l'appelé = Aucune indication

     • Indicateur ISUP = ISUP tout du long

     • Indicateur d’accès RNIS = Terminaison d’accès RNIS

     • Aucune information InBand disponible

     Pour cette situation, un message Progress est envoyé avec ProgressIndicator=9. Ceci est sur NI2c quand aucun message n'est normalement mappé. PI=9 est un message de progression « Vide »; aucune information d'avancement n'est relayée. Il s'agit d'un message vide qui vous permet de relayer les informations GTD pour prendre en charge la transparence ISUP, dans une instance où H.246 n'a normalement aucun message mappé.

     La progression avec PI=9 est envoyée dans les conditions suivantes pour ACM précoce :

     • L'indicateur IsupTransEarlyACMEnable a la valeur 1 pour ce sigPath.

     • Le protocole GTD distant est un protocole ISUP.

     • Les paramètres BCI ne correspondent pas à un message d'alerte/de progression par Q.699/H.246.

     Ceci est rendu configurable avec l'ajout d'une nouvelle propriété NASPATH :

     IsupTransEarlyACMEnable (default = 0) 

     Il est défini sur 1 pour permettre l'envoi de ce message de progression vide sur ACM précoce.

     PI=9 sur la passerelle IOS est associé à l'ID de bogue Cisco CSCea86191 (clients enregistrés uniquement). Si la validation Progress n'est pas activée dans la passerelle, IOS ne vérifie pas les valeurs PI. Ce correctif est disponible dans les versions 12.3 et 12.3T du logiciel Cisco IOS.

   • IsupTransEarlyBackwardDisabled = 1 - Pour plus d'informations sur ce paramètre, reportez-vous à Support of SIP-T and SIP-GTD Feature Overview.

     lapdDropErr = true
     lapdKval = 7
     lapdN200 = 6l
     apdN201 = 260l
     apdT200 = 10l
     apdT203 = 500
     NatureOfAddrHandling = 0
     Normalization = 0
     OMaxDigits = 24
     <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
     OMinDigits = 0
     OOverlap = 0
     OverlapDigitTime = 6
     PostConnectToneDuration = 0
     PostConnectToneValue = 0
     PropagateSvcMsgBlock = true
     RedirectingNbrMap = 0
     RedirMax = 5
     ReleaseMode = Async
     resumeAckTimer = 1
     RoutePref = 0
     rudpAck = enable
     rudpKeepAlives = enable
     rudpNumRetx = 2
     rudpRetxTimer = 6
     rudpSdm = enable
     rudpWindowSz = 32
     sessionPauseTimer = 8
     spanId = ffff
     SuppressCLIDigits = 0
     <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
     T309Time = 90000
     T310Time = 30000
     TMaxDigits = 24
     TMinDigits = 0
     TOverlap = 0
     VOIPPrefix = 0
        */
        ;
     demask mml>
     
     !--- Check the ISUP Transparency on the SS7 link (SS7PATH).
     
     demask mml>prov-rtrv:sigsvcprop:name="ss7path"
        MGC-01 - Media Gateway Controller 2004-05-28 09:55:54.186
      MET
     M  RTRV
        "session=gtd2:sigsvcprop"
        /*
     <snip>
     GRA2 = 0
     GRSEnabled = false
     IsupTransparencyDisabled = 1
     
     !--- ISUP Transparency Disabled – This permits !--- the disabling of the ISUP Transparency feature.
        
     
     !--- Maps to trunk group property IsupTransparencyDisabled. !--- Values are 0 (ISUP Transparency is enabled), 1 !--- (ISUP Transparency is disabled).
     
     LocationNumber = 0
     <snip>
     MaxACL = 3
        */
        ;
     demask mml> 

     Remarque : Le paramètre GTD du profil ne peut pas être modifié lorsqu'il est lié au NAS. Il s'agit de la commande permettant de supprimer la liaison NAS vers GTD.

     demask mml>prov-sta::srcver="active",dstver="gtdremove"
        MGC-01 - Media Gateway Controller 2004-05-28 10:15:28.190 MET
     M  COMPLD
        "PROV-STA"
        ;
     demask mml>prov-dlt:sigsvcprop:name="signas1","gtdcaptypeprop"
        MGC-01 - Media Gateway Controller 2004-05-28 10:17:37.746 MET
     M  COMPLD
        "sigsvcprop"
        ;
     demask mml>prov-cpy
        MGC-01 - Media Gateway Controller 2004-05-28 10:18:33.144 MET
     M  COMPLD
        "PROV-CPY"
        ;
     demask mml> 
     demask mml>prov-rtrv:sigsvcprop:name="signas1"
        MGC-01 - Media Gateway Controller 2004-05-28 10:20:25.961 MET
     M  RTRV
        "session=gtdremove:sigsvcprop"
        /* 

     Cela vous informe que la session GTD est supprimée.

3. Sur la passerelle IOS, définissez la commande globale :

   voice service voip
   signaling forward unconditional

   Sous l'interface série, vous pouvez activer/désactiver la commande isdn gtd .

4. Vérifiez la configuration GTD sur la passerelle.

   debug isdn q931
   		debug voice ccapi inout
     debug voip rawmsg
     debug gtd detail
     debug gtd error
     debug gts events
     debug gtd parser

   Remarque : Si vous rencontrez un problème, insérez ces informations dans la demande de service que vous ouvrez avec l'assistance technique Cisco.

   Si la passerelle Cisco d'entrée est configurée avec une image prenant en charge GTD, la passerelle d'entrée crée des informations GTD et les insère dans le message brut. Il passe ensuite à l'évacuation. La pile RNIS de la passerelle de sortie reçoit ce message brut de VoIP et envoie le message FACILITY dans SETUP. Si vous ne voulez pas ces informations, désactivez-les avec la signalisation CLI forward rawmsg dans le terminal de numérotation dial-peer correspondant (ou activez la signalisation forward rawmsg sous voice service voip). La commande no isdn gtd empêche la pile RNIS de construire GTD.

5. Collectez une trace MDL PGW 2200 si vous rencontrez un problème.Utilisez cette procédure pour collecter une trace MDL via la commande MML sta-sc-trc (Start Trace).

   1. Identifiez le numéro SigPath SS7 d'origine ou le numéro TrunkGroup d'origine sur lequel les appels sont passés.

   2. Faire pivoter le journal : exécutez le script sous /opt/CiscoMGC/bin/log_rotate.sh.

   3. Entrez cette commande pour démarrer la trace MDL :

      mml>sta-sc-trc:
               
               
                 , CONFIRM 
               
      

   4. Effectuer un test (passer un appel).

   5. Entrez cette commande pour arrêter la trace MDL :

      mml>stp-sc-trc:all
      

   6. Identifiez l'ID d'appel (C:) du mauvais appel.

      Si cet appel de test est effectué dans un environnement de test, un seul CALL_ID est affiché.

      Remarque : ces fichiers peuvent contenir des tracés provenant de nombreux appels qui sont tous mélangés si la capture est effectuée sur un Cisco PGW 2200 de production. Chaque enregistrement de suivi dans le fichier a un type d'enregistrement spécifique et enregistre des informations d'un type qui se rapporte à cet enregistrement. Chaque enregistrement possède un ID d'appel qui le relie à un appel spécifique.

   7. Convertir la trace MDL en un format lisible :

      get_trc.sh 
               
               
      

      Tapez ID d'appel à l'invite pour accéder à la trace MDL de l'appel incorrect.

   8. Choisissez l'option C pour convertir le fichier de suivi.

      Remarque : les .btr sont des fichiers de trace binaires qui sont produits par la fonction traceur Cisco PGW 2200. La partie principale du nom de fichier est indiquée dans la commande Cisco PGW 2200 MML sta-sc-trc. Le PGW 2200 ajoute toujours une extension .btr à ces fichiers. Avec l'option C, le fichier est converti en format texte et l'extension possède des fichiers .trc qui sont des fichiers de trace de texte. Ils contiennent des informations détaillées de suivi ligne par ligne du code MDO qui a été exécuté dans la relecture de simulation qui a produit le fichier. Par conséquent, ils contiennent des traces MDL.

      Le fichier de suivi se trouve dans /opt/CiscoMGC/var/trace.

   9. Collectez le fichier platform.log sous /opt/CiscoMGC/var/log.

      Dans certains cas, l'ingénieur de l'assistance technique Cisco peut demander d'autres informations sur platform.log relatives au problème signalé lors du traitement du dossier d'assistance technique.

Informations connexes

• Notes techniques du commutateur logiciel Cisco PGW 2200
• Documentation technique des contrôleurs de signalisation Cisco
• Assistance technique concernant la technologie vocale
• Assistance concernant les produits vocaux et de communications unifiées
• Dépannage des problèmes de téléphonie IP Cisco
• Support technique - Cisco Systems