Voz : H.323

Configuración de control de acceso del Cisco CallManager 3.3

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


Contenido


Introducción

Un dispositivo de gatekeeper, también conocido como Cisco Multimedia Conference Manager (MCM), soporta el mensaje del protocolo de registración, admisión y estado H.225 (RAS) fijado que es funcionando para el control de admisión de llamadas, la asignación de ancho de banda, y la resolución del modelo del dial (ruteo de llamadas). El portero puede proporcionar estos servicios para las comunicaciones entre los clusteres del Cisco CallManager y las redes de H.323. Usted puede configurar los dispositivos de transportador múltiple para cada clúster del Cisco CallManager así como configurar a los gatekeeperes alternativos para la Redundancia. Para los detalles de la configuración del gatekeeper alternativo, refiera a la documentación de MCM.

La configuración de control de acceso con el Cisco CallManager comprende de estos dos pasos:

  1. Configure el portero y el trunk en el Cisco CallManager.

  2. Configure al portero en el router.

prerrequisitos

Requisitos

Este documento se piensa para el personal de redes que despliega las redes de telefonía IP. Quienes lean este documento deben tener conocimiento de los siguientes temas:

  1. Configuración de la voz sobre IP

  2. Conceptos de la Telefonía IP

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • SpB de la versión del CallManager de Cisco 3.3(2) - 171.69.85.171

  • Versión c3640-ix-mz.122-15.T2 del portero IOS� - 172.16.13.7

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Configure el portero y el trunk en el Cisco CallManager

Cada clúster del Cisco CallManager puede registrarse con uno o más porteros. Esta sección describe cómo configurar al portero en el Cisco CallManager. Usted también necesita configurar los dispositivos troncales en la página de la configuración del tronco. Vea la sección de configuración del tronco para los detalles.

Agregue a un portero

Utilice este procedimiento para agregar un dispositivo de gatekeeper.

  1. Seleccione el dispositivo > al portero para visualizar la página de la configuración de control de acceso.

  2. Ingrese las configuraciones apropiadas. Vea el cuadro 1 para más información sobre diversas opciones. Las configuraciones predeterminadas se utilizan para esta configuración.

  3. Separador de millares del tecleo para agregar al nuevo portero.

    La lista de The Gatekeepers visualiza las actualizaciones de la página, y el nombre del nuevo portero.

Opciones de configuración de control de acceso

El cuadro 1 describe las configuraciones de la configuración de control de acceso.

Tabla 1

Campo Descripción
Nombre del host/dirección IP Ingrese el IP Address o el nombre del Sistema de nombres de dominio (DNS) del portero en el campo adecuado. Usted puede registrar a los varios gatekeepers para cada clúster del Cisco CallManager.
Descripción Ingrese un nombre descriptivo para el portero.
Time to Live del pedido de inscripción No cambie este valor a menos que usted tenga una instrucción de hacer tan por un ingeniero de soporte técnico de Cisco. Ingrese el tiempo en los segundos. El valor predeterminado especifica 60 segundos. El campo del Time to Live del pedido de inscripción indica la longitud del tiempo que el portero considera un Solicitud de Inscripción (RRQ) válido. El sistema debe enviar un keepalive RRQ al portero antes de que expire el Time to Live RRQ. El Cisco CallManager envía un RRQ al portero para registrar y mantener posteriormente una conexión con el portero. El portero puede confirmar (RCF) o negar (RRJ) la petición.
Retry timeout del registro No cambie este valor a menos que usted tenga una instrucción de hacer tan por un ingeniero de soporte técnico de Cisco. Ingrese el tiempo en los segundos. El valor predeterminado especifica 300 segundos. El campo del retry timeout del registro indica la longitud del tiempo que el Cisco CallManager espera antes de que revise el registro del extremo del gatekeeper después de que una tentativa fallada del registro.
Habilitar dispositivo Esta casilla de verificación permite que usted registre a este portero con el Cisco CallManager. Por abandono, esta casilla de verificación sigue marcada. Para desregistrar al portero del Cisco CallManager, desmarque esta casilla de verificación. El portero desregistra dentro aproximadamente un minuto después de que usted pone al día este campo.

Usted puede configurar los trunks en la administración del CallManager de Cisco para funcionar de cualquiera de estas maneras:

Nota: Este documento se centra solamente en cómo configurar los trunks del gatekeeper controlado H.225.

Trunk del gatekeeper controlado

En este caso, un solo tronco entre clústerss es suficiente comunicar con todos los clusteres remotos. Semejantemente, un solo trunk H.225 es necesario comunicar con cualquier punto final del gatekeeper controlado de H.323. Usted también necesita configurar los patrones de ruta o a los Grupos de Routes para rutear las llamadas a y desde el portero. En esta configuración, el portero determina dinámicamente el IP Address apropiado para el destino de cada llamada a un dispositivo remoto, y las aplicaciones del CallManager del Cisco local ese IP Address para completar la llamada.

Esta configuración trabaja bien en los sistemas grandes así como más pequeños. Para los grandes sistemas donde existen muchos clusteres, ayudas de esta configuración para evitar la configuración de los trunks individuales del intercluster entre cada cluster.

Si usted configura los trunks del gatekeeper controlado, el Cisco CallManager crea automáticamente un dispositivo del tronco virtual. El IP Address de este dispositivo cambia dinámicamente para reflejar el IP Address del dispositivo remoto que el portero determina. Utilice los trunks cuando usted configura los patrones de ruta o a los Grupos de Routes que rutean las llamadas a y desde un portero.

Agregue un trunk controlado portero H.225

Utilice este procedimiento para agregar un trunk controlado portero H.225.

  1. En el dispositivo > el trunk selectos de la administración del CallManager de Cisco, selectos agregue un nuevo trunk. Usted entonces ve otra página.

  2. Seleccione el trunk H.225 (portero controlado) y después selecciónelo después. Usted entonces ve otra página.

    ccm33-gatekeeper-config-3.gif

  3. Especifique la información del Nombre del dispositivo y de la agrupación de dispositivos. En esta configuración el resto de los valores se dejan como valor por defecto.

    ccm33-gatekeeper-config-4.gif

  4. En la misma página especifique la dirección IP y el tipo de terminal del portero. En la sección del prefijo de tecnología especifique la tecnología apropiada (por ejemplo prefijo 1#*) y en el cuadro de la zona seleccione la zona apropiada (por ejemplo SJGK1).

    ccm33-gatekeeper-config-5.gif

  5. Seleccione el separador de millares y selecciónelo OK al mensaje que indica para reajustar el trunk.

  6. La página restaura. Seleccione para reajustar el trunk y para elegir el reinicio o la restauración apropiadamente.

Configurar un patrón de ruta

Configure a un patrón de ruta para rutear las llamadas a cada trunk del gatekeeper controlado.

Refiera a la configuración del patrón de ruta para más información.

En la configuración del patrón de ruta, especifique el modelo para rutear la llamada hacia el dispositivo troncal.

Este gráfico representa un ejemplo de cómo configurar a un patrón de ruta en el Cisco CallManager. Utilice el modelo de la ruta apropiada según su ruta Plan.

ccm33-gatekeeper-config-6.gif

ccm33-gatekeeper-config-7.gif

Configure al portero en el router

El Cisco CallManager se registra con un portero con el uso de su dirección IP y de H.323 ID. Usted puede especificar el CallManager IP Address en una de estas maneras:

  • En configuración estática, utilice el comando del <address> del ipaddr gw del GW-tipo-prefijo <prefix> en el portero para especificar cada dirección IP del Cisco CallManager explícitamente.

  • En configuración dinámica, cuando un Cisco CallManager se registra con el portero, envía su dirección IP y el prefijo de tecnología especificado al portero. El portero entonces registra este Cisco CallManager como dispositivo de VoIP válido del gatekeeper controlado.

Para especificar el rango del número de directorio para un Cisco CallManager determinado, utilice el comando zone prefix de configurar el rango en el portero. Por ejemplo, este comando especifica el DN para la zona SJGK1 que empieza con el 408-527.

zone prefix SJGK1 408527*

El número máximo de llamadas activas que se permitan para cada zona depende del codificador-decodificador funcionando para cada llamada y el ancho de banda que se afecta un aparato para la zona. El Cisco CallManager pide diversos anchos de banda para diverso codecs:

Códec Ancho de banda pedido por el CallManager
G.711 kpbs 128
G.729 16 kbps
G.723 14 kbps

Utilice las regiones en el Cisco CallManager para especificar el tipo de códec. Utilice el comando bandwidth en el portero para especificar el ancho de banda disponible. Por ejemplo, este comando afecta un aparato 512 kbps a la zona SJGK1.

bandwidth total zone SJGK1 512 

Con una asignación de 512 kbps, la zona SJGK1 en este ejemplo puede soportar hasta:

  • 4 llamadas de G.711 o

  • 32 llamadas de G.729 o

  • 36 llamadas de G.723 al mismo tiempo

Nota: En un escenario donde el portero controla varias zonas, Cisco le recomienda hace uso del comando del interzone del ancho de banda. El comando del total del ancho de banda puede causar los problemas en algunas configuraciones. Para más información sobre las consideraciones acerca del control de acceso, refiera a la sección de configuración de control de acceso centralizada del diseño de red de la referencia de la solución de telefonía de Cisco IP.

Muestree la configuración de control de acceso

interface FastEthernet0/0
 ip address 172.16.13.7 255.255.255.224
 duplex auto
 speed auto

gatekeeper
 zone local SJGK1 cisco.com
 zone prefix SJGK1 408*
 gw-type-prefix 1#* default-technology
 no shutdown


!--- The Cisco CallManager trunks register and appear as VoIP-GW.


3640-1#show gatekeeper endpoints 

                    GATEKEEPER ENDPOINT REGISTRATION
                    ================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type    Flags 
--------------- ----- --------------- ----- ---------         ----    ----- 
171.69.85.31    1720  171.69.85.31         4724     SJGK1             TERM    
    E164-ID: 3166188111
171.69.85.171   4613  171.69.85.171       1160     SJGK1             VOIP-GW 
    H323-ID: TrunkDevice1GK_1
Total number of active registrations = 2

Para más información sobre cómo configurar al portero, refiera al VoIP con Gatekeeper.

Depuraciones

En este escenario de ejemplo, el teléfono del IP hace una llamada para el Cliente NetMeeting de H.323 (el NetMeeting se registra directamente con el portero). El Cisco CallManager entonces envía la llamada al portero a través del tronco gatekeeper. Ésta es la salida para el comando debug ras en el portero.

Oct 15 06:06:22.595: RAS INCOMING PDU ::=

value RasMessage ::= admissionRequest : 
    {
      requestSeqNum 4343
      callType pointToPoint : NULL
      endpointIdentifier {"61C97A1000000001"}
      destinationInfo 
      {
        dialedDigits : "3166188111"
      }
      srcInfo 
      {
        dialedDigits : "4085273175"
      }
      srcCallSignalAddress ipAddress : 
      {
        ip 'AB4555AB'H
        port 1720
      }
      bandWidth 1280
      callReferenceValue 8
      conferenceID '80480FB2D81C911D08000000AC10F07F'H
      activeMC FALSE
      answerCall FALSE
      canMapAlias TRUE
      callIdentifier 
      {
        guid '80480FB2D81C911D08000000AC10F07F'H
      }
      gatekeeperIdentifier {"SJGK1"}
    }

Oct 15 06:06:22.599: ARQ (seq# 4343) rcvd
Oct 15 06:06:22.603: H225 NONSTD OUTGOING PDU ::=

value ACFnonStandardInfo ::= 
    {
      srcTerminalAlias 
      {
        e164 : "4085273175"
      }
      dstTerminalAlias 
      {
        e164 : "3166188111"
      }
    }

Oct 15 06:06:22.603: H225 NONSTD OUTGOING ENCODE BUFFER::= 00 01048073 
B85A64A8 01048064 994BB444 
Oct 15 06:06:22.603: 
Oct 15 06:06:22.603: RAS OUTGOING PDU ::=

value RasMessage ::= admissionConfirm : 
    {
      requestSeqNum 4343
      bandWidth 1280
      callModel direct : NULL
      destCallSignalAddress ipAddress : 
      {
        ip 'AB45551F'H
        port 1720
      }
      irrFrequency 240
      nonStandardData 
      {
        nonStandardIdentifier h221NonStandard : 
        {
          t35CountryCode 181
          t35Extension 0
          manufacturerCode 18
        }
        data '0001048073B85A64A801048064994BB444'H
      }
      willRespondToIRR FALSE
      uuiesRequested 
      {
        setup FALSE
        callProceeding FALSE
        connect FALSE
        alerting FALSE
        information FALSE
        releaseComplete FALSE
        facility FALSE
        progress FALSE
        empty FALSE
      }
    }

Oct 15 06:06:22.611: RAS OUTGOING ENCODE BUFFER::= 2B 8010F640 050000AB 
45551F06 B800EF40 B5000012 11000104 8073B85A 64A
80104 8064994B B4442800 C0000100 020000
Oct 15 06:06:22.615: 
Oct 15 06:06:22.615:  IPSOCK_RAS_sendto:   msg length 48 from 172.16.13.7:1719 
to 171.69.85.171: 1160
Oct 15 06:06:22.615:       RASLib::RASSendACF: ACF (seq# 4343) sent to 171.69.85.171
Oct 15 06:06:25.439:  RecvUDP_IPSockData  successfully rcvd message of 
length 113 from 171.69.85.31:4724
Oct 15 06:06:25.439: RAS INCOMING ENCODE BUFFER::= 26 D0000B03 C0003600 
31004200 38004600 41004500 38003000 30003000 300
03000 30003000 32020480 64994BB4 44048064 994BB444 00AB4555 1F06B800 
00AB4555 AB06B800 013ED080 480FB2D8 1C911D08 000000
AC 10F07F44 E0200100 11008048 0FB2D81C 911D0800 0000AC10 F07F0100 
Oct 15 06:06:25.443: 

Cisco CallManager Trace


!--- Cisco CallManager  sends the RRQ to the gatekeeper.


10/14/2003 23:26:40.082 CCM|value V2Message ::= registrationRequest : 
  {
    requestSeqNum 4372,
    protocolIdentifier { 0 0 8 2250 0 2 },
    discoveryComplete FALSE,
    callSignalAddress 
    {
      ipAddress : 
        {
          ip 'AB4555AB'H,  
          
!--- 171.69.85.171 is the IP address of the Cisco CallManager.

          port 4613
        }
    },
    rasAddress 
    {
      ipAddress : 
        {
          ip 'AB4555AB'H,
          port 1160
        }
    },
    terminalType 
    {
      gateway 
      {
        protocol 
        {
          h323 : 
            {
            },
          voice : 
            {
              supportedPrefixes 
              {
                {
                  prefix e164 : "1#*"
                }
              }
            }
        }
      },
      mc FALSE,
      undefinedNode FALSE
    },
    gatekeeperIdentifier "SJGK1",
    endpointVendor 
    {
      vendor 
      {
        t35CountryCode 181,
        t35Extension 0,
        manufacturerCode 18
      }
    },
    timeToLive 60,
    keepAlive TRUE,
    endpointIdentifier "61C97A1000000001"
  }


!--- Registration is confirmed at this point (there is omission of some output).


10/14/2003 23:26:40.142 CCM|value V2Message ::= registrationConfirm : 
  {
    requestSeqNum 4372,
    protocolIdentifier { 0 0 8 2250 0 4 },
    callSignalAddress 
    {
    },
    gatekeeperIdentifier "SJGK1",
    endpointIdentifier "61C97A1000000001",
    timeToLive 60,
    willRespondToIRR FALSE
  }



!--- Cisco CallManager  sends Admission Request (ARQ) to 
!--- the gatekeeper in order to place the call.


10/14/2003 23:27:26.063 CCM|value V2Message ::= admissionRequest : 
  {
    requestSeqNum 4376,
    callType pointToPoint : NULL,
    endpointIdentifier "61C97A1000000001",
    destinationInfo 
    {
      e164 : "3166188111"
      
!--– This is the phone number of the called 
    !--- party that is the NetMeeting client.

    },
    srcInfo 
    {
      e164 : "4085273175"
     
!--– This is the phone number of the calling party 
     !--- that is the IP phone.

    },
    srcCallSignalAddress ipAddress : 
      {
        ip 'AB4555AB'H,
        port 1720
      },
    bandWidth 1280,
    callReferenceValue 13,
    conferenceID '806076A3DB1C911D0D000000AC10F07F'H,
    activeMC FALSE,
    answerCall FALSE,
    canMapAlias TRUE,
    callIdentifier 
    {
      guid '806076A3DB1C911D0D000000AC10F07F'H
    },
    gatekeeperIdentifier "SJGK1"
  }


!--- This line indicates the client that sends this request.


<NID::171.69.85.171><CT::1,100,90,1.1098993><IP::172.16.240.127>


!--- Here is the Advanced Communications Function (ACF) 
!--- message from the gatekeeper.


10/14/2003 23:27:26.093 CCM|value V2Message ::= admissionConfirm : 
  {
    requestSeqNum 4376,
    bandWidth 1280,
    
!--– For a G.711 call, the bandwidth confirmed is 128 kbps.

    callModel direct : NULL,
    destCallSignalAddress ipAddress : 
      {
        ip 'AB4555AB'H,
        port 4613
      },
    irrFrequency 240,
    nonStandardData 
    {
      nonStandardIdentifier h221NonStandard : 
        {
          t35CountryCode 181,
          t35Extension 0,
          manufacturerCode 18
        },
      data '0001048073B85A64A801048064994BB444'H
    },
    willRespondToIRR FALSE,
    uuiesRequested 
    {
      setup FALSE,
      callProceeding FALSE,
      connect FALSE,
      alerting FALSE,
      information FALSE,
      releaseComplete FALSE,
      facility FALSE,
      progress FALSE,
      empty FALSE
    }
  }



!--- Cisco CallManager displays the RAS information.

10/14/2003 23:27:26.143 CCM|SPROCRas - {
  h323-uu-pdu 
  {
    h323-message-body setup : 
      {
        protocolIdentifier { 0 0 8 2250 0 2 },
        sourceAddress 
        {
          e164 : "4085273175",
          h323-ID : "4085273175"
        },
        sourceInfo 
        {
          terminal 
          {
          },
          mc FALSE,
          undefinedNode FALSE
        },
        destinationAddress 
        {
          e164 : "3166188111"
        },
        activeMC FALSE,
        conferenceID '806076A3DB1C911D0D000000AC10F07F'H,
        conferenceGoal create : NULL,
        callType pointToPoint : NULL,
        sourceCallSignalAddress ipAddress : 
          {
            ip 'AB4555AB'H,
            port 1720
          },
        callIdentifier 
        {
          guid '806076A3DB1C911D0D000000AC10F07F'H
        },
        mediaWaitForConnect FALSE,
        canOverlapSend FALSE
      },
    h245Tunneling FALSE,
    nonStandardControl 
    {
      {
        nonStandardIdentifier h221NonStandard : 
          {
            |<CLID::ADESALU-SUNPC-Cluster><NID::171.69.85.171>
10/14/2003 23:27:26.143 CCM|t35CountryCode 181,
            t35Extension 0,
            manufacturerCode 18
          },
        data '80440400010100'H
      }
    }
  }

Verificación

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshooting

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

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: 44946