Guía de solución de problemas de seguridad relativos a Gateway a Gatekeeper (H.235) y Gatekeeper a Gatekeeper (IZCT)
Contenido
Introducción
Las redes H.323 tienen diferentes tipos de configuraciones y flujos de llamadas. Este documento trata la mayoría de los problemas de seguridad con las redes H.323 que involucran a los gatekeepers. Este documento resume la manera en que funciona cada función y cómo resolver problemas con una explicación sobre la mayoría de las depuraciones. Este documento no aborda la seguridad general de VoIP.
En este documento se describen estas funciones:
-
Intradomain Gateway to Gatekeeper Security: esta seguridad se basa en H.235, en el cual las llamadas H.323 son autenticadas, autorizadas y enrutadas por un gatekeeper. El control de acceso se considera una entidad conocida y de confianza en el sentido de que la puerta de enlace no la autentica cuando la puerta de enlace intenta registrarse con ella.
-
Interdomain Gatekeeper to Gatekeeper Security: esta seguridad cubre la autenticación y autorización de llamadas H.323 entre los dominios administrativos de los proveedores de servicios de telefonía por Internet (ITSP) mediante InterZone Clear Token (IZCT). Este documento cubre solamente la parte donde el gatekeeper de terminación envía un token en su mensaje de confirmación de ubicación (LCF) para que autentique la respuestaSolicitud de admisión de llamada (ARQ). La validación de la solicitud de ubicación (LRQ) no se incluye en esta función. La validación de LRQ es una función programada para una futura versión del software Cisco IOS®.
Definiciones
| Acrónimo | Definición |
|---|---|
| ARQ | Solicitud de admisión: mensaje de Registro, admisión y protocolo de estado (RAS) enviado desde un punto final H.323 a un control de acceso que solicita una admisión para establecer una llamada. |
| ACF | Confirmación de admisión: un mensaje RAS enviado desde el control de acceso al punto final que confirma la aceptación de una llamada. |
| ARJ | Rechazo de admisión: un mensaje RAS del control de acceso al punto final que rechaza la solicitud de admisión. |
| GATO | Token De Acceso De Cisco: El Token Claro H.235. |
| CHAP | Protocolo de autenticación por desafío mutuo: protocolo de autenticación en el que se utiliza un desafío. |
| GCF | Confirmar gatekeeper: un mensaje RAS enviado desde un gatekeeper al punto final H.323 que confirma la detección del gatekeeper. |
| GRQ | Solicitud de gatekeeper: un mensaje RAS enviado desde un punto final H.323 para descubrir el gatekeeper. |
| H.235 | Recomendación de la ITU sobre seguridad y cifrado para los terminales multimedia de la serie H (H.323 y otros basados en H.245). |
| IZCT | InterZone Clear Token: se genera un IZCT en el gatekeeper de origen cuando se inicia un LRQ o se está a punto de enviar un ACF para una llamada intrazone dentro del dominio administrativo ITSP. |
| LRQ | Solicitud de ubicación: un mensaje RAS enviado desde un control de acceso al control de acceso del salto siguiente o al tramo de llamada para rastrear y rutear la llamada. |
| RAS | Registro, admisión y estado: protocolo que permite a un control de acceso realizar el registro, la admisión y las comprobaciones de estado del terminal. |
| RCF | Confirmación de registro: un mensaje RAS enviado desde el gatekeeper al punto final que confirma el registro. |
| RRJ | Rechazo de registro: un mensaje RAS enviado desde el gatekeeper que rechaza la solicitud de registro. |
| RRQ | Solicitud de registro: un mensaje RAS enviado desde el punto final al control de acceso que solicita registrarse con él. |
| RIP | Solicitud en curso: un mensaje RAS enviado desde un control de acceso al remitente que indica que la llamada está en curso. |
Puerta de enlace dentro del dominio para seguridad del control de acceso
H.323 es una recomendación de ITU que aborda la seguridad de la comunicación en tiempo real a través de redes inseguras. Esto implica dos áreas de preocupación principales: autenticación y privacidad. Hay dos tipos de autenticación, según H.235:
-
Autenticación simétrica basada en cifrado que no requiere ningún contacto previo entre las entidades que se comunican.
-
En función de la capacidad de tener algún secreto compartido anterior (también denominado basado en suscripción), se proporcionan dos formas de autenticación basada en suscripción:
-
contraseña
-
certificado
-
Sello de fecha/hora pasado en los token
Se utiliza una marca de tiempo para evitar ataques de repetición. Por lo tanto, es necesario que se haga una referencia mutuamente aceptable a la hora (de la que se obtendrán los sellos de fecha y hora). La cantidad de desviación de tiempo aceptable es una cuestión de implementación local.
Cómo Cisco implementa la recomendación H.235
Cisco utiliza un esquema de autenticación similar al Protocolo de autenticación por desafío mutuo (CHAP, Challenge Handshake Authentication Protocol ) como base para su gateway a la implementación H.235 de su gatekeeper. Esto le permite aprovechar la autenticación, autorización y administración de cuentas (AAA), utilizando la funcionalidad existente para realizar la autenticación real. También significa que el gatekeeper no necesita tener acceso a una base de datos de ID de gateway, números de cuenta de usuario, contraseñas y PIN. El esquema se basa en H.235, sección 10.3.3. Se describe como contraseña basada en suscripción con hash.
Sin embargo, en lugar de utilizar cryptoTokens H.225, este método utiliza clearTokens H.235 con campos rellenados apropiadamente para su uso con RADIUS. Este token se conoce como el token de acceso de Cisco (CAT). Siempre puede realizar la autenticación localmente en el gatekeeper en lugar de utilizar un servidor RADIUS.
El uso de cryptoTokens requiere que el gatekeeper mantenga o tenga alguna manera de adquirir contraseñas para todos los usuarios y gateways. Esto se debe a que el campo de token de cryptoToken se especifica de tal manera que la entidad autenticadora necesita la contraseña para generar su propio token con el cual comparar el recibido.
Los gatekeepers de Cisco ignoran completamente los cryptoTokens. Sin embargo, los gatekeepers de vocalTek y otros que soportan la sección 10.3.3 de H.235 utilizan los cryptoTokens para autenticar el gateway. Los gatekeepers de Cisco utilizan el CAT para autenticar el gateway. Dado que el gateway no sabe con qué tipo de gatekeeper habla, envía ambos en la RRQ. La función authenticationCapability en el GRQ es para el cryptoToken e indica que el hash MD5 es el mecanismo de autenticación (aunque el CAT también utiliza MD5).
Consulte Cisco H.323 Gateway Security and Accounting Enhancements para obtener más información.
Cómo configurar los niveles de seguridad
-
Seguridad de nivel de registro o terminal
Con Registration Security habilitado en el gatekeeper, se requiere que el gateway incluya un CAT en todos los mensajes RRQ de peso pesado. El CAT, en este caso, contiene información que autentica el gateway mismo al gatekeeper. El gatekeeper da formato a un mensaje a un servidor RADIUS que autentica la información contenida en el token. Responde al gatekeeper con un Access-Accept o Access-Reject. Esto, a su vez, responde al gateway con un RCF o un RRJ.
Si se realiza una llamada desde un gateway autenticado correctamente, ese gateway genera un nuevo CAT al recibir un ACF del gatekeeper mediante la contraseña del gateway. Este CAT es idéntico al generado durante el registro excepto por la marca de tiempo. Se coloca en el mensaje de configuración saliente. El gateway de destino extrae el token del mensaje SETUP y lo coloca en el ARQ del lado de destino. El gatekeeper utiliza RADIUS para autenticar el gateway de origen antes de enviar el ACF del lado de destino. Esto evita que un terminal no autenticado que conoce la dirección de una puerta de enlace la utilice para eludir el esquema de seguridad y acceder a la red telefónica pública conmutada (PSTN).
Por lo tanto, en este nivel, no hay necesidad de incluir ningún token en los ARQs de origen.
Escriba [no] security token required-for registration desde la interfaz de línea de comandos (CLI) del gatekeeper para configurar el gatekeeper. La opción no del comando hace que el gatekeeper ya no verifique los tokens en los mensajes RAS.
Escriba [no] security password <PASSWORD> level endpoint desde la CLI de la gateway para configurar la gateway. La opción no del comando hace que el gateway ya no genere tokens para los mensajes RAS.
-
Seguridad por nivel de llamada
La seguridad por llamada se basa en la seguridad de nivel de registro. Además de cumplir con los requisitos de seguridad de registro, también se requiere un gateway para incluir los Tokens de Acceso en todos los mensajes ARQ del lado de origen cuando se habilita la seguridad por llamada en el gatekeeper. El token en este caso contiene información que identifica al usuario del gateway al gatekeeper. Esta información se obtiene mediante un script de respuesta de voz interactiva (IVR) en el gateway. De este modo, los usuarios deberán introducir su ID de usuario y PIN desde el teclado antes de realizar una llamada.
RADIUS autentica el CAT contenido en el ARQ de origen de la misma manera que se describió anteriormente en Endpoint- o Registration-level Security. Después de recibir el ACF, el gateway genera un nuevo CAT usando su contraseña y lo envía dentro del mensaje H.225 SETUP al gateway de terminación.
Escriba [no] security token required-for all en la CLI del gatekeeper para configurar el gatekeeper. La opción no del comando hace que el gatekeeper ya no verifique los tokens en los mensajes RAS.
Escriba [no] security password <PASSWORD> level per-call desde la CLI de la gateway para configurar la gateway. La opción no del comando hace que el gateway ya no genere tokens para los mensajes RAS.
-
Seguridad de todos los niveles
Esto permite que el gateway incluya un CAT en todos los mensajes RAS necesarios para el registro y las llamadas. Por lo tanto, es una combinación de los dos niveles anteriores. Con esta opción, la validación de CAT en los mensajes ARQ se basa en el número de cuenta y el PIN del usuario que realiza una llamada. La validación del CAT enviado en todos los demás mensajes RAS se basa en la contraseña configurada para el gateway. Por lo tanto, es similar al nivel Por llamada.
Escriba [no] security token required-for all en la CLI del gatekeeper para configurar el gatekeeper. La opción no del comando hace que el gatekeeper ya no verifique los tokens en los mensajes RAS.
Escriba [no] security password <PASSWORD> level all en la CLI de la puerta de enlace para configurar la puerta de enlace. La opción no del comando hace que el gateway ya no genere tokens para los mensajes RAS.
Utilización de H.235 en un nivel por llamadas sin IVR
H.235 no se puede utilizar en un nivel por llamada sin IVR. Si no hay IVR para recopilar una cuenta y un PIN, el gateway necesita enviar el ARQ sin un token claro (pero con un token criptográfico). Dado que el gatekeeper de Cisco sólo acepta tokens claros, la llamada es rechazada por el gatekeeper con una razón de negación de seguridad.
Este ejemplo muestra las depuraciones de h225 asn1 recopiladas de un gateway de origen (OGW) que no está configurado para que un IVR recopile la cuenta y el PIN. El mensaje RRQ tiene un token claro, pero el ARQ no. Se devuelve un mensaje ARJ al gateway.
Mar 4 01:31:24.358: H235 OUTGOING ENCODE BUFFER::= 61 000100C0
2B955BEB 08003200 32003200 32000006 006F0067 00770000
Mar 4 01:31:24.358:
Mar 4 01:31:24.358: RAS OUTGOING PDU ::=
value RasMessage ::= registrationRequest :
{
requestSeqNum 29
protocolIdentifier { 0 0 8 2250 0 3 }
discoveryComplete FALSE
callSignalAddress
{
}
rasAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 57514
}
}
terminalType
{
mc FALSE
undefinedNode FALSE
}
gatekeeperIdentifier {"ogk1"}
endpointVendor
{
vendor
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
}
timeToLive 60
tokens
!--- Clear Token is included in the RRQ message.
{
{
tokenOID { 1 2 840 113548 10 1 2 1 }
timeStamp 731208684
challenge 'F57C3C65B59724B9A45C93F98CCF9E45'H
random 12
generalID {"ogw"}
}
}
cryptoTokens
{
cryptoEPPwdHash :
{
alias h323-ID : {"ogw"}
timeStamp 731208684
token
{
algorithmOID { 1 2 840 113549 2 5 }
paramS
{
}
hash "D7F85666AF3B881ADD876DD61C20D5D9"
}
}
}
keepAlive TRUE
endpointIdentifier {"81F5E24800000001"}
willSupplyUUIEs FALSE
maintainConnection TRUE
}
Mar 4 01:31:24.370: RAS OUTGOING ENCODE BUFFER::= 0E 40001C06 0008914A
00030000 0100AC10 0D0FE0AA 0003006F 0067006B 003100B5 00001212 EF000200
3B2F014D 000A2A86 4886F70C 0A010201 C02B955B EB10F57C 3C65B597 24B9A45C
93F98CCF 9E45010C 06006F00 67007700 002A0104 02006F00 670077C0 2B955BEB
082A8648 86F70D02 05008080 D7F85666 AF3B881A DD876DD6 1C20D5D9 0180211E
00380031 00460035 00450032 00340038 00300030 00300030 00300030 00300031
01000180
Mar 4 01:31:24.378: h323chan_dgram_send:Sent UDP msg. Bytes sent: 173 to
172.16.13.35:1719
Mar 4 01:31:24.378: RASLib::GW_RASSendRRQ:
3640-1#debug RRQ (seq# 29) sent to 172.16.13.35
Mar 4 01:31:24.462: h323chan_chn_process_read_socket
Mar 4 01:31:24.462: h323chan_chn_process_read_socket: fd (2) of type CONNECTED has data
Mar 4 01:31:24.462: h323chan_chn_process_read_socket: h323chan accepted/connected
Mar 4 01:31:24.462: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on so
ck[2]
Mar 4 01:31:24.466: RAS INCOMING ENCODE BUFFER::= 12 40001C06 0008914A
00030006 006F0067 006B0031 1E003800 31004600 35004500 32003400 38003000
30003000 30003000 30003000 310F8A01 0002003B 01000180
Mar 4 01:31:24.466:
Mar 4 01:31:24.466: RAS INCOMING PDU ::=
value RasMessage ::= registrationConfirm :
{
requestSeqNum 29
protocolIdentifier { 0 0 8 2250 0 3 }
callSignalAddress
{
}
gatekeeperIdentifier {"ogk1"}
endpointIdentifier {"81F5E24800000001"}
alternateGatekeeper
{
}
timeToLive 60
willRespondToIRR FALSE
maintainConnection TRUE
}
Mar 4 01:31:24.470: RCF (seq# 29) rcvd
Mar 4 01:32:00.220: H225 NONSTD OUTGOING PDU ::=
value ARQnonStandardInfo ::=
{
sourceAlias
{
}
sourceExtAlias
{
}
callingOctet3a 129
interfaceSpecificBillingId "ISDN-VOICE"
}
Mar 4 01:32:00.220: H225 NONSTD OUTGOING ENCODE BUFFER::= 80 000008A0
01810B12 4953444E 2D564F49 4345
Mar 4 01:32:00.220:
Mar 4 01:32:00.220: H235 OUTGOING ENCODE BUFFER::= 61 000100C0
2B955C0F 08003200 32003200 32000006 006F0067 00770000
Mar 4 01:32:00.224:
Mar 4 01:32:00.224: RAS OUTGOING PDU ::=
value RasMessage ::= admissionRequest :
{
requestSeqNum 30
callType pointToPoint : NULL
callModel direct : NULL
endpointIdentifier {"81F5E24800000001"}
destinationInfo
{
e164 : "3653"
}
srcInfo
{
e164 : "5336",
h323-ID : {"ogw"}
}
bandWidth 1280
callReferenceValue 5
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '80000008A001810B124953444E2D564F494345'H
}
conferenceID 'E1575DA6175611CC8014A6051561649A'H
activeMC FALSE
answerCall FALSE
canMapAlias TRUE
callIdentifier
{
guid 'E1575DA6175611CC8015A6051561649A'H
}
cryptoTokens
!--- Only cryptoTokens are included, no clear ones.
{
cryptoEPPwdHash :
{
alias h323-ID : {"ogw"}
timeStamp 731208720
token
{
algorithmOID { 1 2 840 113549 2 5 }
paramS
{
}
hash "105475A4C0A833E7DE8E37AD3A8CDFF"
}
}
}
willSupplyUUIEs FALSE
}
Mar 4 01:32:00.236: RAS OUTGOING ENCODE BUFFER::= 27 88001D00 F0003800
31004600 35004500 32003400 38003000 30003000 30003000 30003000 31010180
69860201 80866940 02006F00 67007740 05000005 40B50000 12138000 0008A001
810B1249 53444E2D 564F4943 45E1575D A6175611 CC8014A6 05156164 9A056120
01801100 E1575DA6 175611CC 8015A605 1561649A 2A010402 006F0067 0077C02B
955C0F08 2A864886 F70D0205 00808010 5475A4C0 A833E7DE 8E370AD3 A8CDFF01 00
Mar 4 01:32:00.240: h323chan_dgram_send:Sent UDP msg. Bytes sent: 170 to
172.16.13.35:1719
Mar 4 01:32:00.240: RASLib::GW_RASSendARQ: ARQ (seq# 30) sent to 172.16.13.35
Mar 4 01:32:00.312: h323chan_chn_process_read_socket
Mar 4 01:32:00.312: h323chan_chn_process_read_socket: fd (2) of type CONNECTED has data
Mar 4 01:32:00.312: h323chan_chn_process_read_socket: fd (2) of type CONNECTED has data
Mar 4
3640-1#01:32:00.312: h323chan_chn_process_read_socket: h323chan accepted/connected
Mar 4 01:32:00.312: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on so
ck[2]
Mar 4 01:32:00.312: RAS INCOMING ENCODE BUFFER::= 2C 001D8001 00
Mar 4 01:32:00.312:
Mar 4 01:32:00.312: RAS INCOMING PDU ::=
value RasMessage ::= admissionReject :
!--- ARQ is rejected with a security denial reason.
{
requestSeqNum 30
rejectReason securityDenial : NULL
}
Mar 4 01:32:00.312: ARJ (seq# 30) rcvd
Aspectos importantes
Entre los principales problemas que debe tener en cuenta se incluyen los siguientes:
-
Configuración del gateway y el gatekeeper
-
Configuración de RADIUS en el gatekeeper y el servidor RADIUS
-
Protocolo de tiempo de la red (NTP): debe tener la misma hora en todos los gateways y gatekeepers. Dado que la información de autenticación incluye una marca de tiempo, es importante que todas las gateways H.323 de Cisco y los gatekeepers (u otra entidad que realice la autenticación) estén sincronizados. Las gateways H.323 de Cisco deben sincronizarse mediante NTP.
-
Error de software debido a un error
Depuraciones y flujo de llamada para los diferentes niveles
Dado que todos los niveles de seguridad cubren tanto el registro como los casos por llamada, el laboratorio se configura con ese nivel de seguridad para este ejercicio. Los flujos de llamadas para la parte de registro y una llamada VoIP normal se explican en la configuración aquí.
Nota: La configuración no está completa. Se siguen más comandos entre los resultados de depuración. Está diseñado para mostrar qué problema puede ocurrir si no verifica todos los elementos como la configuración, NTP y RADIUS. Además, el gateway se autentica localmente en el gatekeeper para que pueda ver qué valores se establecen para el ID y la contraseña del gateway. Esta configuración se recorta para que solo se muestre la configuración relacionada.
! interface Ethernet0/0 ip address 172.16.13.15 255.255.255.224 half-duplex h323-gateway voip interface h323-gateway voip id gka-1 ipaddr 172.16.13.35 1718 !--- The gatekeeper name is gka-1. h323-gateway voip h323-id gwa-1@cisco.com !--- The gateway H323-ID is gwa-1@cisco.com. h323-gateway voip tech-prefix 1# ! ! gateway ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 password ww logging synchronous end !--- No NTP is configured. !--- The snipped gatekeeper configuration is like this: ! aaa new-model aaa authentication login default local aaa authentication login h323 local aaa authorization exec default local aaa authorization exec h323 local aaa accounting connection h323 start-stop group radius ! username gwa-1 password 0 2222 username gwa-2 password 0 2222 ! gatekeeper zone local gka-1 cisco.com 172.16.13.35 security token required-for all !--- The gatekeeper is configured for the "All level security". no shutdown ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 password ww line vty 5 15 ! no scheduler max-task-time no scheduler allocate ntp master !--- This gatekeeper is set as an NTP master. ! end
Estas depuraciones se activan en este ejemplo:
Lo primero que ocurre es que el gateway envía un GRQ al gatekeeper y el gatekeeper envía un GCF al gateway. A continuación, el gateway envía una RRQ y espera un RCF o un RRJ.
En la configuración anterior, el gateway no está configurado para ningún nivel de seguridad, de modo que su GRQ no lleva ninguna authenticationCapability necesaria para los tokens. Sin embargo, el gatekeeper aún envía un GCF como muestra este resultado:
*Mar 2 13:32:45.413: RAS INCOMING ENCODE BUFFER::= 00 A0000006
0008914A 000200AC 100D0FD2 C6088001 3C050401 00204002 00006700 6B006100
2D003102 400E0067 00770061 002D0031 00400063 00690073 0063006F 002E0063
006F006D 0080CC
*Mar 2 13:32:45.421:
*Mar 2 13:32:45.425: RAS INCOMING PDU ::=
value RasMessage ::= gatekeeperRequest :
{
requestSeqNum 1
protocolIdentifier { 0 0 8 2250 0 2 }
rasAddress ipAddress :
{
ip 'AC100D0F'H
port 53958
}
endpointType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
{
prefix e164 : "1#"
}
}
}
}
}
mc FALSE
undefinedNode FALSE
}
gatekeeperIdentifier {"gka-1"}
endpointAlias
{
h323-ID : {"gwa-1@cisco.com"},
!--- The H.323-ID of the gateway is gwa-1@cisco.com.
e164 : "99"
}
}
*Mar 2 13:32:45.445: RAS OUTGOING PDU ::=
value RasMessage ::= gatekeeperConfirm :
{
requestSeqNum 1
protocolIdentifier { 0 0 8 2250 0 3 }
gatekeeperIdentifier {"gka-1"}
rasAddress ipAddress :
{
ip 'AC100D23'H
port 1719
}
}
!--- The gateway sends an RRQ message to the gatekeeper with the
!--- IP address sent in the GCF. This RRQ does not carry any Token information
!--- because security is not configured on the gateway.
*Mar 2 13:32:45.477: RAS INCOMING ENCODE BUFFER::= 0E C0000106 0008914A
00028001 00AC100D 0F06B801 00AC100D 0FD2C608 80013C05 04010020 40000240
0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006D00
80CC0800 67006B00 61002D00 3100B500 00120E8A 02003B01 000100
*Mar 2 13:32:45.489:
*Mar 2 13:32:45.493: RAS INCOMING PDU ::=
value RasMessage ::= registrationRequest :
{
requestSeqNum 2
protocolIdentifier { 0 0 8 2250 0 2 }
discoveryComplete TRUE
callSignalAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 1720
}
}
rasAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 53958
}
}
terminalType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
{
prefix e164 : "1#"
}
}
}
}
}
mc FALSE
undefinedNode FALSE
}
terminalAlias
{
h323-ID : {"gwa-1@cisco.com"},
e164 : "99"
}
gatekeeperIdentifier {"gka-1"}
endpointVendor
{
vendor
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
}
timeToLive 60
keepAlive FALSE
willSupplyUUIEs FALSE
}
!--- Since the gateway does not include
!--- any tokens and the gatekeeper is set to authenticate
!--- all endpoints and calls, the gatekeeper rejects the gateway request.
!--- It sends an RRJ with the securityDenial reason.
*Mar 2 13:32:45.525: RAS OUTGOING PDU ::=
value RasMessage ::= registrationReject :
{
requestSeqNum 2
protocolIdentifier { 0 0 8 2250 0 3 }
rejectReason securityDenial : NULL
!--- Gatekeeper rejects the RRQ with security denial reason.
gatekeeperIdentifier {"gka-1"}
}
*Mar 2 13:32:45.529: RAS OUTGOING ENCODE BUFFER::= 14 80000106
0008914A 00038301 00080067 006B0061 002D0031
*Mar 2 13:32:45.533:
!--- Configure the security password 2222 level all command on the gateway.
!--- The configuration of the gateway appears like this:
!
gateway
security password 0356095954 level all
!--- The password is hashed.
!
!--- As soon as you make this change the gateway
!--- sends a new GRQ to the gatekeeper.
!--- You see the authenticationCapability and algorithmOIDs.
*Mar 2 13:33:15.551: RAS INCOMING ENCODE BUFFER::= 02 A0000206
0008914A 000200AC 100D0FD2 C6088001 3C050401 00204002 00006700 6B006100
2D003102 400E0067 00770061 002D0031 00400063 00690073 0063006F 002E0063
006F006D 0080CC0C 30020120 0A01082A 864886F7 0D0205
*Mar 2 13:33:15.563:
*Mar 2 13:33:15.567: RAS INCOMING PDU ::=
value RasMessage ::= gatekeeperRequest :
{
requestSeqNum 3
protocolIdentifier { 0 0 8 2250 0 2 }
rasAddress ipAddress :
{
ip 'AC100D0F'H
port 53958
}
endpointType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
{
prefix e164 : "1#"
}
}
}
}
}
mc FALSE
undefinedNode FALSE
}
gatekeeperIdentifier {"gka-1"}
endpointAlias
{
h323-ID : {"gwa-1@cisco.com"},
e164 : "99"
}
authenticationCapability
{
pwdHash : NULL
}
algorithmOIDs
{
{ 1 2 840 113549 2 5 }
}
}
Esto explica algunos de los mensajes en el GRQ:
-
authenticationCapability: este campo sólo tiene el valor de pwdHash. Indica que el hash MD5 es el mecanismo de autenticación.
-
algorithmOIDs: el ID de objeto del algoritmo. En este caso, lleva el valor (1 2 840 113549 2 5), que es la ID de objeto del hash de Message Digest 5.
(1 2 840 113549 2 5) se traduce en iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) md5(5). Por lo tanto, Cisco utiliza hash de contraseña MD5.
Rsadsi significa RSA data security Inc. El identificador de objeto Open Systems Interconnection (OSI) de RSA Data Security, Inc. es 1.2.840.113549 (0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d en hexadecimal), según lo registrado por el American National Standards Institute (ANSI).
El gatekeeper nuevamente envía un GCF como el mensaje anterior. El gateway luego envía una RRQ con ciertos campos para describir los tokens que utiliza para ser autenticado. El mensaje asn1 RRQ que se envía se muestra en este ejemplo.
*Mar 2 13:33:15.635: RAS INCOMING ENCODE BUFFER::= 0E C0000306
0008914A 00028001 00AC100D 0F06B801 00AC100D 0FD2C608 80013C05 04010020
40000240 0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300
6F006D00 80CC0800 67006B00 61002D00 3100B500 00120EEA 02003B47 014D000A
2A864886 F70C0A01 0201C02B 92A53610 B9D84DAE 58F6CB4B 5EE5DFB6 B92DD281
01011E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00
6D000042 01040E00 67007700 61002D00 31004000 63006900 73006300 6F002E00
63006F00 6DC02B92 A536082A 864886F7 0D020500 80802B21 B94F3980 ED12116C
56B79F4B 4CDB0100 0100
*Mar 2 13:33:15.667:
*Mar 2 13:33:15.671: RAS INCOMING PDU ::=
value RasMessage ::= registrationRequest :
{
requestSeqNum 4
protocolIdentifier { 0 0 8 2250 0 2 }
discoveryComplete TRUE
callSignalAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 1720
}
}
rasAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 53958
}
}
terminalType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
{
prefix e164 : "1#"
}
}
}
}
}
mc FALSE
undefinedNode FALSE
}
terminalAlias
{
h323-ID : {"gwa-1@cisco.com"},
e164 : "99"
}
gatekeeperIdentifier {"gka-1"}
endpointVendor
{
vendor
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
}
timeToLive 60
tokens
!--- Clear Token, or what is called CAT.
{
{
tokenOID { 1 2 840 113548 10 1 2 1 }
timeStamp 731030839
challenge 'B9D84DAE58F6CB4B5EE5DFB6B92DD281'H
random 1
generalID {"gwa-1@cisco.com"}
}
}
cryptoTokens
!--- CryptoToken field.
{
cryptoEPPwdHash :
{
alias h323-ID : {"gwa-1@cisco.com"}
timeStamp 731030839
token
{
algorithmOID { 1 2 840 113549 2 5 }
paramS
{
}
hash "2B21B94F3980ED12116C56B79F4B4CDB"
}
}
}
keepAlive FALSE
willSupplyUUIEs FALSE
}
Antes de discutir la respuesta, aquí se explican algunos de los campos relacionados en el mensaje de RRQ anterior. Hay dos tipos de tokens: un token claro o CAT) y un token criptográfico.
Como se mencionó anteriormente, los gatekeepers de Cisco ignoran los tokens criptográficos. Sin embargo, la puerta de enlace todavía envía ambos porque no sabe a qué tipo de gatekeeper está hablando. Dado que otros proveedores podrían utilizar tokens criptográficos, el gateway envía ambos.
Esto explica la sintaxis de ClearToken.
-
tokenOID: el ID de objeto para identificar el token.
-
timeStamp: la hora universal coordinada (UTC) actual del gateway. Segundos desde 00:00 1/1/1970 UTC.
Se utiliza como un CHAP-Challenge implícito como si hubiera venido inicialmente del gatekeeper.
-
desafío: resumen de mensajes MD5 de 16 bytes generado por la puerta de enlace que utiliza estos campos:
challenge = [ random + GW/User Password + timeStamp ] Hash MD5
RADIUS realiza este cálculo (ya que conoce el número aleatorio, la contraseña del gateway y el desafío CHAP) para determinar cuál debe ser el desafío: Respuesta CHAP = [ ID de CHAP + Contraseña de Usuario + Desafío CHAP ] Hash MD5
-
random: valor de un byte utilizado por RADIUS para identificar esta solicitud en particular.
El gateway incrementa un módulo variable de 256 por cada solicitud de autenticación para satisfacer este requisito RADIUS.
-
generalID: el gateway H323-ID o el número de cuenta de usuario según el nivel de seguridad y el tipo de mensaje RAS.
Nota: Todos estos campos son importantes. Sin embargo, se presta más atención tanto a la marca de tiempo como a la identificación general. En este caso, la marca de tiempo es 731030839 y el identificador general es gwa-1@cisco.com.
El cryptoToken en la RRQ contiene información sobre el gateway que genera el token. Esto incluye el ID de gateway (que es el ID H.323 configurado en el gateway) y la contraseña del gateway.
Este campo contiene uno de los tipos cryptoToken definidos para el campo CryptoH323Token especificado en H.225. Actualmente, el único tipo de cryptoToken admitido es cryptoEPPwdHash.
Estos campos están incluidos en el campo cryptoEPPwdHash:
-
alias: el alias del gateway, que es el ID H.323 del gateway.
-
timestamp: la marca de tiempo actual.
-
token: PwdCertToken codificado en Message Digest 5 (MD5). Este campo contiene los siguientes elementos:
-
timestamp: el mismo que el timestamp del cryptoEPPwdHash.
-
password: la contraseña del gateway.
-
generalID: el mismo alias de gateway que el incluido en cryptoEPPwdHash.
-
tokenID: el ID de objeto.
-
Vea la respuesta del gatekeeper en este ejemplo.
*Mar 2 13:33:15.723: RAS OUTGOING PDU ::=
value RasMessage ::= registrationReject :
{
requestSeqNum 4
protocolIdentifier { 0 0 8 2250 0 3 }
rejectReason securityDenial : NULL
!--- The gatekeeper rejects the RRQ with securityDenial reason.
gatekeeperIdentifier {"gka-1"}
}
*Mar 2 13:33:15.727: RAS OUTGOING ENCODE BUFFER::= 14 80000306 0008914A
00038301 00080067 006B0061 002D0031
*Mar 2 13:33:15.731:
El gatekeeper rechaza la RRQ. Esto se debe a que no había ningún NTP configurado en la configuración del gateway. El gatekeeper verifica la marca de tiempo del token para ver si se encuentra dentro de una ventana aceptable en relación con su propio tiempo. Actualmente esta ventana es de +/- 30 segundos alrededor del tiempo UTC del gatekeeper.
Un token fuera de esta ventana hace que el gatekeeper descarte este mensaje. Esto evita los ataques de repetición de alguien que intenta reutilizar un token indagado. En la práctica, todos los gateways y gatekeepers deben utilizar NTP para evitar este problema de desviación de tiempo. El gatekeeper encuentra que la marca de tiempo en el token está dentro de la ventana aceptable de su tiempo. Por lo tanto, no verifica con RADIUS para autenticar el gateway.
La gateway se configura entonces para que el NTP apunte al gatekeeper como el maestro NTP, de modo que tanto la gateway como el gatekeeper tengan el mismo tiempo. Cuando esto ocurre, el gateway envía una nueva RRQ y esta vez el gatekeeper responde a la nueva RRQ con un RRJ.
Estas depuraciones son del gatekeeper. Las depuraciones se ejecutan para ver si el gatekeeper va a la fase de autenticación.
Mar 2 13:57:41.313: RAS INCOMING ENCODE BUFFER::= 0E C0005906 0008914A
00028001 00AC100D 0F06B801 00AC100D 0FD2C608 80013C05 04010020 40000240
0E006700 77006100 2D003100 40006300 69007300 63006F00 2E006300 6F006D00
80CC0800 67006B00 61002D00 3100B500 00120EEA 02003B47 014D000A 2A864886
F70C0A01 0201C02B 9367D410 7DD4C637 B6DD4E34 0883A7E5 E12A2B78 012C1E00
67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00 6D000042
01040E00 67007700 61002D00 31004000 63006900 73006300 6F002E00 63006F00
6DC02B93 67D4082A 864886F7 0D020500 8080ED73 946B13E9 EAED6F4D FED13478
A6270100 0100
Mar 2 13:57:41.345:
Mar 2 13:57:41.349: RAS INCOMING PDU ::=
value RasMessage ::= registrationRequest :
{
requestSeqNum 90
protocolIdentifier { 0 0 8 2250 0 2 }
discoveryComplete TRUE
callSignalAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 1720
}
}
rasAddress
{
ipAddress :
{
ip 'AC100D0F'H
port 53958
}
}
terminalType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
{
prefix e164 : "1#"
}
}
}
}
}
mc FALSE
undefinedNode FALSE
}
terminalAlias
{
h323-ID : {"gwa-1@cisco.com"},
e164 : "99"
}
gatekeeperIdentifier {"gka-1"}
endpointVendor
{
vendor
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
}
timeToLive 60
tokens
{
{
tokenOID { 1 2 840 113548 10 1 2 1 }
timeStamp 731080661
challenge '7DD4C637B6DD4E340883A7E5E12A2B78'H
random 44
generalID {"gwa-1@cisco.com"}
}
}
cryptoTokens
{
cryptoEPPwdHash :
{
alias h323-ID : {"gwa-1@cisco.com"}
timeStamp 731080661
token
{
algorithmOID { 1 2 840 113549 2 5 }
paramS
{
}
hash "ED73946B13E9EAED6F4DFED13478A627"
}
}
}
keepAlive FALSE
willSupplyUUIEs FALSE
}
Mar 2 13:57:41.401: AAA: parse name=<no string> idb type=-1 tty=-1
Mar 2 13:57:41.405: AAA/MEMORY: create_user (0x81416060) user='gwa-1@cisco.com'
ruser='NULL' ds0=0port='NULL' rem_addr='NULL' authen_type=CHAP
service=LOGIN priv=0 initial_task_id='0'
Mar 2 13:57:41.405: AAA/AUTHEN/START (2845574558): port='' list='h323'
action=LOGIN service=LOGIN
Mar 2 13:57:41.405: AAA/AUTHEN/START (2845574558): found list h323
Mar 2 13:57:41.405: AAA/AUTHEN/START (2845574558): Method=LOCAL
Mar 2 13:57:41.405: AAA/AUTHEN (2845574558): User not found, end of method list
Mar 2 13:57:41.405: AAA/AUTHEN (2845574558): status = FAIL
!--- Authentication fails. The user is not found on the list.
Mar 2 13:57:41.405: voip_chapstyle_auth: astruct.status = 2
Mar 2 13:57:41.405: AAA/MEMORY: free_user (0x81416060) user='gwa-1@cisco.com'
ruser='NULL' port='NULL' rem_addr='NULL' authen_type=CHAP service=LOGIN priv=0
Mar 2 13:57:41.409: RAS OUTGOING PDU ::=
value RasMessage ::= registrationReject :
{
requestSeqNum 90
protocolIdentifier { 0 0 8 2250 0 3 }
rejectReason securityDenial : NULL
gatekeeperIdentifier {"gka-1"}
}
Después de configurar NTP, el gatekeeper todavía rechaza la RRQ. Esta vez, sin embargo, pasa por el proceso de autenticación para ese gateway. El gatekeeper rechaza el RRQ porque el usuario (aquí el ID de gateway) no se encuentra en la lista de usuarios válidos en el RADIUS. El gateway se autentica localmente en la configuración del gatekeeper. En la lista de usuarios verá gwa-1. Sin embargo, no es el usuario correcto, ya que el usuario de la RRQ es gwa-1@cisco.com.
Además, una vez que se configura el comando username gwa-1@cisco.com password 0 2222 en el gatekeeper, el gatekeeper confirma la RRQ y el gateway se registra.
En este laboratorio, otra gateway (gwa-2) se registra en el mismo gatekeeper (gka-1). Se realiza una llamada desde gwa-1@cisco.com a gwa-2 para ver cómo se ven los mensajes ARQ, ACF y setup.
Estas depuraciones recopiladas provienen de la puerta de enlace de origen y de destino (gwa-2).
Se incluye una explicación de algunos de los mensajes de depuración.
Antes de imprimir los debugs desde la gateway de origen/terminación, este texto explica el flujo de llamada:
-
Cuando se recibe un mensaje SETUP desde la PSTN, la gateway envía un ARQ a y recibe un ACF del gatekeeper.
-
Cuando el gateway recibe el ACF, el gateway genera un CAT utilizando la contraseña del gateway, el alias H323-ID y la hora actual. El token se coloca en el bloque de control de llamadas (CCB).
-
Cuando el gateway envía el mensaje SETUP al gateway de terminación, recupera el token de acceso del CCB y lo coloca en el campo nonStandardParameter de un clearToken dentro del mensaje SETUP.
-
El gateway de terminación quita el token del mensaje SETUP, lo convierte de un nonStandardParameter a un CAT y lo coloca en el ARQ.
-
El gatekeeper verifica la marca de tiempo del token para ver si se encuentra dentro de una ventana aceptable en relación con su propio tiempo. Actualmente esta ventana es de +/- 30 segundos alrededor del tiempo UTC del gatekeeper. Un token fuera de esta ventana hace que el gatekeeper descarte este mensaje. Esto hace que se rechace la llamada.
-
Si el token es aceptable, el gatekeeper da formato a un paquete de solicitud de acceso RADIUS, completa los atributos apropiados para verificar un desafío CHAP y lo envía a un servidor RADIUS.
-
Basándose en la suposición de que el alias del gateway se conoce en el servidor, el servidor localiza la contraseña asociada con este alias y genera su propia respuesta CHAP utilizando el alias, la contraseña y el desafío CHAP del control de acceso. Si su respuesta CHAP coincide con la recibida del gatekeeper, el servidor envía un paquete de aceptación de acceso al gatekeeper. Si no coinciden, o si el alias del gateway no está en la base de datos del servidor, el servidor envía un paquete de rechazo de acceso al control de acceso.
-
El gatekeeper responde al gateway con un ACF si recibe una aceptación de acceso, o un ARJ con código de causa securityDenial si recibe un rechazo de acceso. Si la puerta de enlace recibe un ACF, la llamada se conecta.
Este ejemplo muestra la depuración del gateway de origen.
Nota: Las depuraciones de h225 asn1 para la configuración no se encuentran en este ejemplo, ya que es el mismo que se ve en el ejemplo de gateway de terminación que sigue al ejemplo de gateway de origen.
Mar 2 19:39:07.376: cc_api_call_setup_ind (vdbPtr=0x6264AB2C,
callInfo={called=3653,called_oct3=0x81,calling=,calling_oct3=0x81,calling_oct3a=0x0,
calling_xlated=false,subscriber_type_str=RegularLine,fdest=1,peer_tag=5336,
prog_ind=3},callID=0x61DDC2A8)
Mar 2 19:39:07.376: cc_api_call_setup_ind type 13 , prot 0
Mar 2 19:39:07.376: cc_process_call_setup_ind (event=0x6231F0C4)
Mar 2 19:39:07.380: >>>>CCAPI handed cid 30 with tag 5336 to app "DEFAULT"
Mar 2 19:39:07.380: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(30), disp(0)
Mar 2 19:39:07.380: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(30), disp(0)
Mar 2 19:39:07.380: ssaCallSetupInd
Mar 2 19:39:07.380: ccCallSetContext (callID=0x1E, context=0x6215B5A0)
Mar 2 19:39:07.380: ssaCallSetupInd cid(30), st(SSA_CS_MAPPING),oldst(0),
ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
Mar 2 19:39:07.380: ssaCallSetupInd finalDest cllng(1#5336), clled(3653)
Mar 2 19:39:07.380: ssaCallSetupInd cid(30), st(SSA_CS_CALL_SETTING),oldst(0),
ev(24)dpMatchPeersMoreArg result= 0
Mar 2 19:39:07.380: ssaSetupPeer cid(30) peer list: tag(3653) called number (3653)
Mar 2 19:39:07.380: ssaSetupPeer cid(30), destPat(3653), matched(4), prefix(),
peer(62664554), peer->encapType (2)
Mar 2 19:39:07.380: ccCallProceeding (callID=0x1E, prog_ind=0x0)
Mar 2 19:39:07.380: ccCallSetupRequest (Inbound call = 0x1E, outbound peer =3653,
dest=, params=0x62327730 mode=0, *callID=0x62327A98, prog_ind = 3)
Mar 2 19:39:07.380: ccCallSetupRequest numbering_type 0x81
Mar 2 19:39:07.380: ccCallSetupRequest encapType 2 clid_restrict_disable 1
null_orig_clg 1 clid_transparent 0 callingNumber 1#5336
Mar 2 19:39:07.380: dest pattern 3653, called 3653, digit_strip 0
Mar 2 19:39:07.380: callingNumber=1#5336, calledNumber=3653, redirectNumber=
display_info= calling_oct3a=0
Mar 2 19:39:07.384: accountNumber=, finalDestFlag=1,
guid=6aef.3a87.165c.11cc.8040.d661.b74f.9390
Mar 2 19:39:07.384: peer_tag=3653
Mar 2 19:39:07.384: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=,
callParams={called=3653,called_oct3=0x81, calling=1#5336,calling_oct3=0x81,
calling_xlated=false, subscriber_type_str=RegularLine, fdest=1,
voice_peer_tag=3653},mode=0x0) vdbPtr type = 1
Mar 2 19:39:07.384: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=,
callParams={called=3653, called_oct3 0x81, calling=1#5336,calling_oct3
0x81, calling_xlated=false, fdest=1, voice_peer_tag=3653}, mode=0x0, xltrc=-5)
Mar 2 19:39:07.384: ccSaveDialpeerTag (callID=0x1E, dialpeer_tag=0xE45)
Mar 2 19:39:07.384: ccCallSetContext (callID=0x1F, context=0x621545DC)
Mar 2 19:39:07.384: ccCallReportDigits (callID=0x1E, enable=0x0)
Mar 2 19:39:07.384: cc_api_call_report_digits_done (vdbPtr=0x6264AB2C,
callID=0x1E, disp=0)
Mar 2 19:39:07.384: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE), cid(30),disp(0)
Mar 2 19:39:07.384: cid(30)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)
Mar 2 19:39:07.384: -cid2(31)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING)
Mar 2 19:39:07.384: ssaReportDigitsDone cid(30) peer list: (empty)
Mar 2 19:39:07.384: ssaReportDigitsDone callid=30 Reporting disabled.
Mar 2 19:39:07.388: H225 NONSTD OUTGOING PDU ::=
value ARQnonStandardInfo ::=
{
sourceAlias
{
}
sourceExtAlias
{
}
interfaceSpecificBillingId "ISDN-VOICE"
}
Mar 2 19:39:07.388: H225 NONSTD OUTGOING ENCODE BUFFER::= 80 00000820
0B124953 444E2D56 4F494345
Mar 2 19:39:07.388:
Mar 2 19:39:07.388: H235 OUTGOING ENCODE BUFFER::= 61 000100C0 2B93B7DA
08003200 32003200 3200001E 00670077 0061002D 00310040 00630069 00730063
006F002E 0063006F 006D0000
Mar 2 19:39:07.392:
Mar 2 19:39:07.392: RAS OUTGOING PDU ::=
value RasMessage ::= admissionRequest :
!--- The ARQ is sent to the gatekeeper.
{
requestSeqNum 549
callType pointToPoint : NULL
callModel direct : NULL
endpointIdentifier {"8155346000000001"}
destinationInfo
{
e164 : "2#3653"
}
srcInfo
{
e164 : "1#5336",
h323-ID : {"gwa-1@cisco.com"}
}
bandWidth 640
callReferenceValue 15
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '80000008200B124953444E2D564F494345'H
}
conferenceID '6AEF3A87165C11CC8040D661B74F9390'H
activeMC FALSE
answerCall FALSE
canMapAlias TRUE
callIdentifier
{
guid '6AEF3A87165C11CC8041D661B74F9390'H
}
tokens
!--- Token is included since there is an all level of security.
{
{
tokenOID { 1 2 840 113548 10 1 2 1 }
timeStamp 731101147
challenge '1CADDBA948A8291C1F134035C9613E3E'H
random 246
generalID {"gwa-1@cisco.com"}
}
}
cryptoTokens
{
cryptoEPPwdHash :
{
alias h323-ID : {"gwa-1@cisco.com"}
timeStamp 731101147
token
{
algorithmOID { 1 2 840 113549 2 5 }
paramS
{
}
hash "5760B7B4877335B7CD24BD24E4A2AA89"
}
}
}
willSupplyUUIEs FALSE
}
Mar 2 19:39:07.408: RAS OUTGOING ENCODE BUFFER::= 27 88022400 F0003800
31003500 35003300 34003600 30003000 30003000 30003000 30003000 31010280
50698602 02804086 69400E00 67007700 61002D00 31004000 63006900 73006300
6F002E00 63006F00 6D400280 000F40B5 00001211 80000008 200B1249 53444E2D
564F4943 456AEF3A 87165C11 CC8040D6 61B74F93 9004E320 01801100 6AEF3A87
165C11CC 8041D661 B74F9390 48014D00 0A2A8648 86F70C0A 010201C0 2B93B7DA
101CADDB A948A829 1C1F1340 35C9613E 3E0200F6 1E006700 77006100 2D003100
40006300 69007300 63006F00 2E006300 6F006D00 00420104 0E006700 77006100
2D003100 40006300 69007300 63006F00 2E006300 6F006DC0 2B93B7DA 082A8648
86F70D02 05008080 5760B7B4 877335B7 CD24BD24 E4A2AA89 0100
Mar 2 19:39:07.412: h323chan_dgram_send:Sent UDP msg. Bytes sent: 291 to
172.16.13.35:1719
Mar 2 19:39:07.416: RASLib::GW_RASSendARQ: ARQ (seq# 549) sent to 172.16.13.35
Mar 2 19:39:07.432: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719] on sock[1]
Mar 2 19:39:07.432: RAS INCOMING ENCODE BUFFER::= 2B 00022440 028000AC
100D1706 B800EF1A 00C00100 020000
Mar 2 19:39:07.432:
Mar 2 19:39:07.432: RAS INCOMING PDU ::=
value RasMessage ::= admissionConfirm :
!--- Received from the gatekeeper with no tokens.
{
requestSeqNum 549
bandWidth 640
callModel direct : NULL
destCallSignalAddress ipAddress :
{
ip 'AC100D17'H
port 1720
}
irrFrequency 240
willRespondToIRR FALSE
uuiesRequested
{
setup FALSE
callProceeding FALSE
connect FALSE
alerting FALSE
information FALSE
releaseComplete FALSE
facility FALSE
progress FALSE
empty FALSE
}
}
Mar 2 19:39:07.436: ACF (seq# 549) rcvd
Este ejemplo muestra las depuraciones de la gateway de terminación (TGW). Observe que el TGW ha configurado el segundo tramo desde que obtuvo ACF, y la llamada está conectada.
Mar 2 19:39:07.493: PDU DATA = 6147C2BC
value H323_UserInformation ::=
{
h323-uu-pdu
{
h323-message-body setup :
{
protocolIdentifier { 0 0 8 2250 0 2 }
sourceAddress
{
h323-ID : {"gwa-1@cisco.com"}
!--- Setup is sent from gwa-1@cisco.com gateway.
}
sourceInfo
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
{
prefix e164 : "1#"
}
}
}
}
}
mc FALSE
undefinedNode FALSE
}
activeMC FALSE
conferenceID '6AEF3A87165C11CC8040D661B74F9390'H
conferenceGoal create : NULL
callType pointToPoint : NULL
sourceCallSignalAddress ipAddress :
{
ip 'AC100D0F'H
port 11032
}
callIdentifier
{
guid '6AEF3A87165C11CC8041D661B74F9390'H
}
tokens
!--- Setup includes the Clear Token (CAT).
{
{
tokenOID { 1 2 840 113548 10 1 2 1 }
timeStamp 731101147
challenge 'AFBAAFDF79446B9D8CE164DB8C111A87'H
random 247
generalID {"gwa-1@cisco.com"}
nonStandard
{
nonStandardIdentifier { 0 1 2 4 }
data '2B93B7DBAFBAAFDF79446B9D8CE164DB8C111A87...'H
}
}
}
fastStart
{
'0000000C6013800A04000100AC100D0F4673'H,
'400000060401004C6013801114000100AC100D0F...'H
}
mediaWaitForConnect FALSE
canOverlapSend FALSE
}
h245Tunneling TRUE
nonStandardControl
{
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data 'E001020001041504039090A31803A983811E0285...'H
}
}
}
}
RAW_BUFFER::=
E0 01020001 04150403 9090A318 03A98381 1E028583 70058133 36353302 80060004
00000003
Mar 2 19:39:07.509: PDU DATA = 6147F378
value H323_UU_NonStdInfo ::=
{
version 2
protoParam qsigNonStdInfo :
{
iei 4
rawMesg '04039090A31803A983811E028583700581333635...'H
}
progIndParam progIndIEinfo :
{
progIndIE '00000003'H
}
}
PDU DATA = 6147F378
value ARQnonStandardInfo ::=
{
sourceAlias
{
}
sourceExtAlias
{
}
}
RAW_BUFFER::=
00 0000
Mar 2 19:39:07.517: RAW_BUFFER::=
61 000100C0 2B93B7DA 08003200 32003200 3200000A 00670077 0061002D
00320000
Mar 2 19:39:07.517: PDU DATA = 6147C2BC
value RasMessage ::= admissionRequest :
!--- An answer ARQ is sent to the gatekeeper to authenticate the caller.
{
requestSeqNum 22
callType pointToPoint : NULL
callModel direct : NULL
endpointIdentifier {"81F5989C00000002"}
destinationInfo
{
e164 : "2#3653"
}
srcInfo
{
e164 : "1#5336"
}
srcCallSignalAddress ipAddress :
{
ip 'AC100D0F'H
port 11032
}
bandWidth 640
callReferenceValue 2
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '000000'H
}
conferenceID '6AEF3A87165C11CC8040D661B74F9390'H
activeMC FALSE
answerCall TRUE
canMapAlias FALSE
callIdentifier
{
guid '6AEF3A87165C11CC8041D661B74F9390'H
}
tokens
!--- CAT is included.
{
{
tokenOID { 0 4 0 1321 1 2 }
timeStamp 731101147
challenge 'AFBAAFDF79446B9D8CE164DB8C111A87'H
random 247
generalID {"gwa-1@cisco.com"}
}
}
cryptoTokens
{
cryptoEPPwdHash :
{
alias h323-ID : {"gwa-2"}
timeStamp 731101147
token
{
algorithmOID { 1 2 840 113549 2 5 }
paramS
{
}
hash "8479E7DE63AC17C6A46E9E19659568"
}
}
}
willSupplyUUIEs FALSE
}
RAW_BUFFER::=
27 98001500 F0003800 31004600 35003900 38003900 43003000 30003000 30003000
30003000 32010280 50698601 02804086 6900AC10 0D0F2B18 40028000 0240B500
00120300 00006AEF 3A87165C 11CC8040 D661B74F 939044E3 20010011 006AEF3A
87165C11 CC8041D6 61B74F93 9044014D 00060400 8A290102 C02B93B7 DA10AFBA
AFDF7944 6B9D8CE1 64DB8C11 1A870200 F71E0067 00770061 002D0031 00400063
00690073 0063006F 002E0063 006F006D 00002E01 04040067 00770061 002D0032
C02B93B7 DA082A86 4886F70D 02050080 808479E7 0DE63AC1 7C6A46E9 E1965905
680100
Mar 2 19:39:07.533: h323chan_dgram_send:Sent UDP msg. Bytes sent: 228
to 172.16.13.35:1719
Mar 2 19:39:07.533: RASLib::GW_RASSendARQ: ARQ (seq# 22) sent to 172.16.13.35
Mar 2 19:39:07.549: h323chan_dgram_recvdata:rcvd from [172.16.13.35:1719]
on sock[1]
RAW_BUFFER::=
2B 00001540 028000AC 100D1706 B800EF1A 00C00100 020000
Mar 2 19:39:07.549: PDU DATA = 6147C2BC
value RasMessage ::= admissionConfirm :
!--- ACF is received from the gatekeeper.
{
requestSeqNum 22
bandWidth 640
callModel direct : NULL
destCallSignalAddress ipAddress :
{
ip 'AC100D17'H
port 1720
}
irrFrequency 240
willRespondToIRR FALSE
uuiesRequested
{
setup FALSE
callProceeding FALSE
connect FALSE
alerting FALSE
information FALSE
releaseComplete FALSE
facility FALSE
progress FALSE
empty FALSE
}
}
Mar 2 19:39:07.553: ACF (seq# 22) rcvd
Mar 2 19:39:07.553: cc_api_call_setup_ind (vdbPtr=0x61BC92EC,
callInfo={called=2#3653,called_oct3=0x81,calling=1#5336,calling_oct3=0x81,
calling_oct3a=0x0,subscriber_type_str=Unknown, fdest=1 peer_tag=5336,
prog_ind=3},callID=0x6217CC64)
Mar 2 19:39:07.553: cc_api_call_setup_ind type 0 , prot 1
Mar 2 19:39:07.553: cc_api_call_setup_ind (vdbPtr=0x61BC92EC,
callInfo={called=2#3653, calling=1#5336, fdest=1 peer_tag=5336},
callID=0x6217CC64)
Mar 2 19:39:07.553: cc_process_call_setup_ind (event=0x61E1EAFC)
Mar 2 19:39:07.553: >>>>CCAPI handed cid 9 with tag 5336 to app "DEFAULT"
Mar 2 19:39:07.553: sess_appl: ev(25=CC_EV_CALL_SETUP_IND), cid(9), disp(0)
Mar 2 19:39:07.553: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(9), disp(0)
Mar 2 19:39:07.553: ssaCallSetupInd
Mar 2 19:39:07.553: ccCallSetContext (callID=0x9, context=0x62447A28)
Mar 2 19:39:07.553: ssaCallSetupInd cid(9), st(SSA_CS_MAPPING),oldst(0),
ev(25)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
Mar 2 19:39:07.553: ssaCallSetupInd finalDest cllng(1#5336), clled(2#3653)
Mar 2 19:39:07.553: ssaCallSetupInd cid(9), st(SSA_CS_CALL_SETTING),oldst(0),
ev(25)dpMatchPeersMoreArg result= 0
Mar 2 19:39:07.557: ssaSetupPeer cid(9) peer list: tag(3653)
called number (2#3653)
Mar 2 19:39:07.557: ssaSetupPeer cid(9), destPat(2#3653), matched(5),
prefix(21), peer(620F1EF0), peer->encapType (1)
Mar 2 19:39:07.557: ccCallProceeding (callID=0x9, prog_ind=0x0)
Mar 2 19:39:07.557: ccCallSetupRequest (Inbound call = 0x9, outbound peer
=3653, dest=, params=0x61E296C0 mode=0, *callID=0x61E299D0, prog_ind = 3)
Mar 2 19:39:07.557: ccCallSetupRequest numbering_type 0x81
Mar 2 19:39:07.557: dest pattern 2#3653, called 2#3653, digit_strip 1
Mar 2 19:39:07.557: callingNumber=1#5336, calledNumber=2#3653,
redirectNumber=display_info= calling_oct3a=0
Mar 2 19:39:07.557: accountNumber=, finalDestFlag=1,
guid=6aef.3a87.165c.11cc.8040.d661.b74f.9390
Mar 2 19:39:07.557: peer_tag=3653
Mar 2 19:39:07.557: ccIFCallSetupRequestPrivate: (vdbPtr=0x61E4473C, dest=,
callParams={called=2#3653,called_oct3=0x81, calling=1#5336,calling_oct3=0x81,
subscriber_type_str=Unknown, fdest=1, voice_peer_tag=3653},mode=0x0) vdbPtr
type = 6
Mar 2 19:39:07.557: ccIFCallSetupRequestPrivate: (vdbPtr=0x61E4473C, dest=,
callParams={called=2#3653, called_oct3 0x81, calling=1#5336,calling_oct3 0x81,
fdest=1, voice_peer_tag=3653}, mode=0x0, xltrc=-4)
Mar 2 19:39:07.557: ccSaveDialpeerTag (callID=0x9, dialpeer_tag=
Mar 2 19:39:07.557: ccCallSetContext (callID=0xA, context=0x6244D9EC)
Mar 2 19:39:07.557: ccCallReportDigits (callID=0x9, enable=0x0)
Problemas con el IOS de la gateway
En el mismo laboratorio, la imagen del IOS 12.2(6a) se carga en el OGW. Cuando se realiza una llamada, se observa que el OGW todavía envía un token claro basado en su contraseña aunque el gateway no esté configurado para que IVR recopile la cuenta/PIN. Además, el gatekeeper configurado para el nivel all acepta esa llamada. Esto se documenta en la identificación de error de Cisco CSCdw43224 (sólo para clientes registrados) .
Seguridad con puntos finales alternativos
Como se mencionó anteriormente en este documento, la seguridad de llamadas de extremo a extremo se proporciona con el uso de tokens de acceso que se envían en el campo clearTokens en los mensajes RAS/H.225. Al habilitar dicha seguridad, el gateway de origen reenvía el token de acceso recibido del gatekeeper en un ACF al punto final H.323 de destino en el mensaje H.225 SETUP. Este punto final H.323 de destino reenvía el token de acceso recibido en el mensaje SETUP al gatekeeper en su solicitud de admisión. Al hacer esto, le da al gatekeeper remoto la capacidad de admitir llamadas basándose en la validez del token de acceso. El contenido del token de acceso depende de la entidad que lo genera. Para minimizar los agujeros de seguridad y protegerse contra los ataques de intrusos, los gatekeepers pueden codificar información específica de destino en el token de acceso. Esto significa que cuando se proporcionan puntos finales alternativos en un ACF, el gatekeeper puede proporcionar un token de acceso independiente para cada punto final alternativo especificado.
Cuando intenta establecer una conexión por primera vez, el gateway de Cisco envía el token de acceso que ha recibido en el campo clearToken del ACF con la dirección en el campo destCallSignalAddress. Si este intento no tiene éxito y la puerta de enlace de Cisco continúa intentando establecer conexiones con un terminal alternativo, utiliza el token de acceso asociado (si está disponible) de la lista de terminales alternativos. Si la lista de terminales alternativos recibida en ACF no incluye tokens de acceso, pero ACF incluye un token de acceso, el gateway de Cisco incluye este token de acceso en todos los intentos de conectarse con un terminal alternativo.
Soporte de Token OSP
Actualmente, el protocolo de liquidación abierta (OSP) y sus tokens solo se admiten en los gateways de Cisco. No hay soporte en el gatekeeper. El gateway reconoce los tokens OSP recibidos de un servidor de liquidación y los inserta en el mensaje de configuración Q.931 a un gateway de terminación.
Diferentes niveles de seguridad para cada punto final o zona
Actualmente no puede configurar diferentes niveles de seguridad para cada terminal o zona. El nivel de seguridad es para todas las zonas administradas por ese gatekeeper. Se puede abrir una solicitud de característica para dicho problema.
Controlador de acceso entre dominios a Seguridad de controlador de acceso
La seguridad de gatekeeper a gatekeeper entre dominios proporciona la capacidad de validar las solicitudes de gatekeeper a gatekeeper entre dominios y entre dominios por salto. Esto significa que el gatekeeper de destino termina el CAT y genera uno nuevo si el gatekeeper decide reenviar el LRQ hacia adelante. Si el gatekeeper detecta una firma LRQ no válida, responde enviando un LRJ (Location Reject).
Implemente Gatekeeper a Gatekeeper Security
El gatekeeper de origen genera un IZCT cuando se inicia un LRQ o cuando se está a punto de enviar un ACF en caso de una llamada dentro de la zona. Este token se atraviesa a través de su ruta de enrutamiento. A lo largo de la trayectoria, cada gatekeeper actualiza el ID de gatekeeper de destino y/o el ID de gatekeeper de origen, si es necesario, para reflejar la información de la zona. El gatekeeper de terminación genera un token con su contraseña. Este token se transporta en los mensajes de confirmación de ubicación (LCF) y se pasa a OGW. El OGW incluye este token en el mensaje H.225 SETUP. Cuando el TGW recibe el token, es reenviado en la respuesta de llamada ARQ y validado por el gatekeeper de terminación (TGK) sin necesidad de un servidor RADIUS.
El tipo de autenticación se basa en la contraseña con hash, como se describe en ITU H.235. En concreto, el método de cifrado es MD5 con hash de contraseña.
El propósito del IZCT es saber si el LRQ ha llegado de un dominio extranjero, de qué zona y de qué portador. También se utiliza para pasar un token al OGW en el LCF desde el TGK. En el formato IZCT, esta información es obligatoria:
-
srcCarrierID: identificación del operador de origen
-
dstCarrierID: identificación de portadora de destino
-
intCarrierID: identificación de portadora intermedia
-
srcZone: zona de origen
-
dstZone: zona de destino
-
tipo entre zonas
-
INTRA_DOMAIN_CISCO
-
INTER_DOMAIN_CISCO
-
INTRA_DOMAIN_TERM_NOT_CISCO
-
INTER_DOMAIN_ORIG_NOT_CISCO
-
Esta función funciona correctamente sin necesidad de un ID de operador de la puerta de enlace o de un servidor de enrutamiento sensible a la portadora (CSR). En tal caso, los campos sobre el ID de transportista están vacíos. Los ejemplos aquí descritos no incluyen ningún ID de operador. Para obtener información detallada sobre el flujo de llamadas, el soporte de la plataforma y la versión, y las configuraciones, refiérase a Mejora de la Seguridad del Gatekeeper entre Dominios.
Configuración de Gatekeeper (control de acceso)
La función IZCT requiere esta configuración en el gatekeeper.
Router(gk-config)# [no] security izct password
La contraseña debe tener entre seis y ocho caracteres. Identifique qué zona está en un dominio externo como este:
Router(config-gk)# zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address [port-number] [cost cost-value [priority priority-value]] [foreign-domain]
Flujo de llamada IZCT
Este diagrama muestra el flujo IZCT.
En esta configuración, los nombres de los gateways y los gatekeepers son los mismos que los utilizados en el diagrama de flujo de llamadas IZCT pero con minúsculas. El flujo de llamadas se explica después de la configuración, con explicaciones de depuración.
Para explicar la función IZCT y el flujo de llamadas, el primer ejemplo no tiene la gateway intradomain a la seguridad del gatekeeper. Después de eso, hay ejemplos donde el TGW no puede generar el IZCT para que el TGK1 rechace la llamada. Esto es para mostrar que la función funciona según lo diseñado. Todas estas configuraciones se basan en la topología del diagrama de flujo de llamadas IZCT.
Ejemplo 1: Flujo de llamadas solo para la seguridad de gatekeeper a gatekeeper
Este ejemplo muestra las configuraciones relacionadas de todos los gateways y gatekeepers.
| Configuración de OGW | Configuración de TGW |
|---|---|
! hostname ogw !controller E1 3/0 pri-group timeslots 1-2,16 ! interface Ethernet0/0 ip address 172.16.13.15 255.255.255.224 half-duplex h323-gateway voip interface h323-gateway voip id ogk1 ipaddr 172.16.13.35 1718 h323-gateway voip h323-id ogw h323-gateway voip tech-prefix 1# ! voice-port 3/0:15 ! dial-peer voice 5336 pots incoming called-number . destination-pattern 5336 direct-inward-dial port 3/0:15 prefix 21 ! dial-peer voice 3653 voip incoming called-number . destination-pattern 3653 session target ras dtmf-relay h245-alphanumeric codec g711ulaw ! gateway ! ntp clock-period 17178791 ntp server 172.16.13.35 end |
hostname tgw ! controller E1 0 clock source line primary ds0-group 0 timeslots 1-2 type r2-digital r2-compelled ! interface Ethernet0 ip address 172.16.13.23 255.255.255.224 h323-gateway voip interface h323-gateway voip id tgk1 ipaddr 172.16.13.41 1718 h323-gateway voip h323-id tgw h323-gateway voip tech-prefix 2# ! voice-port 0:0 compand-type a-law ! dial-peer voice 3653 pots application test1 incoming called-number . destination-pattern 3653 port 0:0 prefix 21 ! dial-peer voice 5336 voip incoming called-number . destination-pattern 5336 session target ras dtmf-relay h245-alphanumeric codec g711ulaw ! gateway ! ntp clock-period 17179814 ntp server 172.16.13.35 end |
| Configuración de OGK1 | Configuración de TGK1 |
|---|---|
! hostname ogk1 ! interface Ethernet0/0 ip address 172.16.13.35 255.255.255.224 half-duplex ! gatekeeper zone local ogk1 domainA.com 172.16.13.35 zone remote ogk2 domainA.com 172.16.13.14 1719 zone prefix ogk2 36* zone prefix ogk1 53* security izct password 111222 gw-type-prefix 1#* default- technology no shutdown ! ! no scheduler max-task-time no scheduler allocate ntp master ! end |
! hostname tgk1 ! interface Ethernet0/0 ip address 172.16.13.41 255.255.255.224 ip directed-broadcast half-duplex ! gatekeeper zone local tgk1 domainB.com 172.16.13.41 zone remote tgk2 domainB.com 172.16.13.16 1719 zone prefix tgk1 36* zone prefix tgk2 53* security izct password 111222 gw-type-prefix 2#* default- technology no shutdown ! ntp clock-period 17179797 ntp server 172.16.13.35 ! end |
| Configuración de OGK2 | Configuración de TGK2 |
|---|---|
! hostname ogk2 ! interface Ethernet0/0 ip address 172.16.13.14 255.255.255.224 full-duplex ! gatekeeper zone local ogk2 domainA.com zone remote ogk1 domainA.com 172.16.13.35 1719 zone remote tgk2 domainB.com 172.16.13.16 1719 foreign-domain zone prefix tgk2 36* zone prefix ogk1 53* security izct password 111222 lrq forward-queries no shutdown ! ntp clock-period 17208242 ntp server 172.16.13.35 ! end |
! hostname tgk2 ! interface Ethernet0/0 ip address 172.16.13.16 255.255.255.224 half-duplex ! gatekeeper zone local tgk2 domainB.com zone remote tgk1 domainB.com 172.16.13.41 1719 zone remote ogk2 domainA.com 172.16.13.14 1719 foreign-domain zone prefix tgk1 36* zone prefix ogk2 53* security izct password 111222 lrq forward-queries no shutdown ! ntp clock-period 17179209 ntp server 172.16.13.35 ! end |
Flujo de llamadas con depuración
Estos ejemplos utilizan los debugs para explicar el flujo de llamadas.
-
Un usuario del operador E llama a un usuario del operador D.
Mar 4 15:31:19.989: cc_api_call_setup_ind (vdbPtr=0x6264ADF0, callInfo={called=3653, called_oct3=0x80,calling=4085272923,calling_oct3=0x21,calling_oct3a=0x80 calling_xlated=false,subscriber_type_str=RegularLine,fdest=1,peer_tag=5336, prog_ind=0},callID=0x6219F9F0) Mar 4 15:31:19.993: cc_api_call_setup_ind type 13 , prot 0 Mar 4 15:31:19.993: cc_process_call_setup_ind (event=0x6231A6B4) Mar 4 15:31:19.993: >>>>CCAPI handed cid 7 with tag 5336 to app "DEFAULT" Mar 4 15:31:19.993: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(7), disp(0) Mar 4 15:31:19.993: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(7), disp(0) Mar 4 15:31:19.993: ssaCallSetupInd Mar 4 15:31:19.993: ccCallSetContext (callID=0x7, context=0x621533F0) Mar 4 15:31:19.997: ssaCallSetupInd cid(7), st(SSA_CS_MAPPING),oldst(0), ev(24) ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1 Mar 4 15:31:19.997: ssaCallSetupInd finalDest cllng(4085272923), clled(3653) Mar 4 15:31:19.997: ssaCallSetupInd cid(7), st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0 Mar 4 15:31:19.997: ssaSetupPeer cid(7) peer list: tag(3653) called number (3653) Mar 4 15:31:19.997: ssaSetupPeer cid(7), destPat(3653), matched(4), prefix(), peer(626640B0), peer->encapType (2) Mar 4 15:31:19.997: ccCallProceeding (callID=0x7, prog_ind=0x0) Mar 4 15:31:19.997: ccCallSetupRequest (Inbound call = 0x7, outbound peer=3653, dest=, params=0x62327730 mode=0, *callID=0x62327A98, prog_ind = 0) Mar 4 15:31:19.997: ccCallSetupRequest numbering_type 0x80 Mar 4 15:31:19.997: ccCallSetupRequest encapType 2 clid_restrict_disable 1 null _orig_clg 0 clid_transparent 0 callingNumber 4085272923 Mar 4 15:31:19.997: dest pattern 3653, called 3653, digit_strip 0 Mar 4 15:31:19.997: callingNumber=4085272923, calledNumber=3653, redirectNumber = display_info= calling_oct3a=80 Mar 4 15:31:19.997: accountNumber=, finalDestFlag=1, guid=221b.686c.17cc.11cc.8010.a049.e052.4766 Mar 4 15:31:19.997: peer_tag=3653 Mar 4 15:31:19.997: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=, callParams={called=3653,called_oct3=0x80, calling=4085272923,calling_oct3=0x21, calling_xlated=false, subscriber_type_str=RegularLine, fdest=1, voice_peer_tag=365 3},mode=0x0) vdbPtr type = 1 Mar 4 15:31:19.997: ccIFCallSetupRequestPrivate: (vdbPtr=0x621B2360, dest=, callParams={called=3653, called_oct3 0x80, calling=4085272923,calling_oct3 0x21, calling_xlated=false, fdest=1, voice_peer_tag=3653}, mode=0x0, xltrc=-5) Mar 4 15:31:20.001: ccSaveDialpeerTag (callID=0x7, dialpeer_tag=0xE45) Mar 4 15:31:20.001: ccCallSetContext (callID=0x8, context=0x6215388C) Mar 4 15:31:20.001: ccCallReportDigits (callID=0x7, enable=0x0) -
Dado que el dialpeer del gateway de origen (tag=3653) está configurado para RAS, envía un ARQ a OGK1.
Mar 4 15:31:20.001: H225 NONSTD OUTGOING PDU ::= value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } callingOctet3a 128 interfaceSpecificBillingId "ISDN-VOICE" } Mar 4 15:31:20.005: H225 NONSTD OUTGOING ENCODE BUFFER::= 80 000008A0 01800B12 4953444E 2D564F49 4345 Mar 4 15:31:20.005: Mar 4 15:31:20.005: RAS OUTGOING PDU ::= value RasMessage ::= admissionRequest : !--- ARQ is sent out to ogk1. { requestSeqNum 1109 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"81567A4000000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "4085272923", h323-ID : {"ogw"} } bandWidth 640 callReferenceValue 4 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008A001800B124953444E2D564F494345'H } conferenceID '221B686C17CC11CC8010A049E0524766'H activeMC FALSE answerCall FALSE canMapAlias TRUE callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } willSupplyUUIEs FALSE } Mar 4 15:31:20.013: RAS OUTGOING ENCODE BUFFER::= 27 88045400 F0003800 31003500 36003700 41003400 30003000 30003000 30003000 30003000 31010180 69860204 8073B85A 5C564002 006F0067 00774002 80000440 B5000012 13800000 08A00180 0B124953 444E2D56 4F494345 221B686C 17CC11CC 8010A049 E0524766 04E02001 80110022 1B686C17 CC11CC80 11A049E0 52476601 00 Mar 4 15:31:20.017: h323chan_dgram_send:Sent UDP msg. Bytes sent: 130 to 172.16.13.35:1719 Mar 4 15:31:20.017: RASLib::GW_RASSendARQ: ARQ (seq# 1109) sent to 172.16.13.35 -
Cuando OGK1 recibe el ARQ, determina que el destino es atendido por la zona remota OGK2. Luego identifica que se necesita un IZCT ( a través de CLI: security izct password <pwd>). OGK1 procede a crear el IZCT antes de que se envíe el LRQ. A continuación, envía IZCT y LRQ a OGK2 y envía un mensaje RIP de vuelta a OGW.
Mar 4 15:31:19.927: H225 NONSTD OUTGOING PDU ::= value LRQnonStandardInfo ::= { ttl 6 nonstd-callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } callingOctet3a 128 gatewaySrcInfo { e164 : "4085272923", h323-ID : {"ogw"} } } Mar 4 15:31:19.935: H225 NONSTD OUTGOING ENCODE BUFFER::= 82 86B01100 221B686C 17CC11CC 8011A049 E0524766 01801002 048073B8 5A5C5640 02006F00 670077 Mar 4 15:31:19.939: Mar 4 15:31:19.939: PDU ::= value IZCToken ::= !--- The gatekeeper creates and sends out the IZCT. { izctInterZoneType intraDomainCisco : NULL !--- The destination is in the same domain, it is intraDomainCisco type. izctSrcZone "ogk1" !--- The source zone is ogk1. ) Mar 4 15:31:19.943: ENCODE BUFFER::= 07 00C06F67 6B310473 72630464 73740469 6E74 Mar 4 15:31:19.947: Mar 4 15:31:19.947: RAS OUTGOING PDU ::= value RasMessage ::= locationRequest : !--- LRQ is sent out to ogk2. { requestSeqNum 2048 destinationInfo { e164 : "3653" } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '8286B01100221B686C17CC11CC8011A049E05247...'H } replyAddress ipAddress : { ip 'AC100D23'H port 1719 } sourceInfo { h323-ID : {"ogk1"} } canMapAlias TRUE tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '0700C06F676B31047372630464737404696E74'H } } } } Mar 4 15:31:19.967: RAS OUTGOING ENCODE BUFFER::= 4A 8007FF01 01806986 40B50000 12288286 B0110022 1B686C17 CC11CC80 11A049E0 52476601 80100204 8073B85A 5C56400 2 006F0067 007700AC 100D2306 B70BA00B 01400300 6F006700 6B003101 802B0100 80092A 86 4886F70C 0A010009 2A864886 F70C0A01 00130700 C06F676B 31047372 63046473 74046 96E 74 Mar 4 15:31:19.983: Mar 4 15:31:19.987: IPSOCK_RAS_sendto: msg length 122 from 172.16.13.35:1719 to 172.16.13.14: 1719 Mar 4 15:31:19.987: RASLib::RASSendLRQ: LRQ (seq# 2048) sent to 172.16.13.14 Mar 4 15:31:19.987: RAS OUTGOING PDU ::= value RasMessage ::= requestInProgress : !--- RIP message is sent back to OGW. { requestSeqNum 1109 delay 9000 } Mar 4 15:31:19.991: RAS OUTGOING ENCODE BUFFER::= 80 05000454 2327 Mar 4 15:31:19.991: Mar 4 15:31:19.991: IPSOCK_RAS_sendto: msg length 7 from 172.16.13.35:1719 to 172.16.13.15: 57076 Mar 4 15:31:19.991: RASLib::RASSendRIP: RIP (seq# 1109) sent to 172.16.13.15 -
Cuando OGK2 recibe el LRQ, verifica el IZCT. A partir de la configuración, se encuentra que LRQ no puede contener también un IZCT. A continuación, OGK2 crea un nuevo IZCT al cambiar izctSrcZone e izctDstZone a ogk2 y reenvía el LRQ a TGK2. Después de enviar el LRQ a TGK2, devuelve un mensaje RIP a OGK1.
Si los gatekeepers son parte de un cluster, el nombre del cluster se utiliza para SrcZone o DstZone.
Mar 4 15:31:20.051: RAS OUTGOING PDU ::= value RasMessage ::= requestInProgress : !--- RIP message is sent back to OGK1. { requestSeqNum 2048 delay 6000 } Mar 4 15:31:20.055: RAS OUTGOING ENCODE BUFFER::= 80 050007FF 176F Mar 4 15:31:20.055: Mar 4 15:31:20.055: IPSOCK_RAS_sendto: msg length 7 from 172.16.13.14:1719 to 172.16.13.35: 1719 Mar 4 15:31:20.059: RASLib::RASSendRIP: RIP (seq# 2048) sent to 172.16.13.35 Mar 4 15:31:20.059: H225 NONSTD OUTGOING PDU ::= value LRQnonStandardInfo ::= { ttl 5 nonstd-callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } callingOctet3a 128 gatewaySrcInfo { e164 : "4085272923", h323-ID : {"ogw"} } } Mar 4 15:31:20.063: H225 NONSTD OUTGOING ENCODE BUFFER::= 82 06B01100 221B686C 17CC11CC 8011A049 E0524766 01801002 048073B8 5A5C5640 02006F00 670077 Mar 4 15:31:20.072: Mar 4 15:31:20.072: PDU ::= value IZCToken ::= { izctInterZoneType intraDomainCisco : NULL !--- This is still intraDomain since message OGK1 is !--- not a foreign domain. izctSrcZone "ogk2" !--- ScrZone and DstZone become ogk2. izctDstZone "ogk2" } Mar 4 15:31:20.076: ENCODE BUFFER::= 47 00C06F67 6B32066F 676B3204 73726304 64737404 696E74 Mar 4 15:31:20.080: Mar 4 15:31:20.080: RAS OUTGOING PDU ::= value RasMessage ::= locationRequest : !--- The LRQ is forwarded to TGK2. { requestSeqNum 2048 destinationInfo { e164 : "3653" } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '8206B01100221B686C17CC11CC8011A049E05247...'H } replyAddress ipAddress : { ip 'AC100D23'H port 1719 } sourceInfo { h323-ID : {"ogk1"} } canMapAlias TRUE tokens !--- IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '4700C06F676B32066F676B320473726304647374...'H } } } } Mar 4 15:31:20.104: RAS OUTGOING ENCODE BUFFER::= 4A 8007FF01 01806986 40B50000 12288206 B0110022 1B686C17 CC11CC80 11A049E0 52476601 80100204 8073B85A 5C564002 006F0067 007700AC 100D2306 B70BA00B 01400300 6F006700 6B003101 80300100 80092A86 4886F70C 0A010009 2A864886 F70C0A01 00184700 C06F676B 32066F67 6B320473 72630464 73740469 6E74 Mar 4 15:31:20.120: Mar 4 15:31:20.120: IPSOCK_RAS_sendto: msg length 127 from 172.16.13.14:1719 to 172.16.13.16: 1719 Mar 4 15:31:20.124: RASLib::RASSendLRQ: LRQ (seq# 2048) sent to 172.16.13.16 -
TGK2 determina que el LRQ proviene de un dominio externo. Actualiza dstZone de IZCT con su propio ID e interZoneType como INTER_DOMAIN_CISCO. A continuación, crea un nuevo CAT y pasa el IZCT actualizado y el LRQ a TGK1.
TGK2 trata la zona desde la cual se recibe un LRQ como una zona de dominio externo en cualquiera de estos dos escenarios:
-
La lista de zonas remotas de TGK2 no contiene la zona desde la cual se recibe un LRQ.
-
La lista de zonas remotas de TGK2 contiene la zona desde la cual se recibe un LRQ. La zona está marcada con un indicador de dominio externo.
A continuación, envía un mensaje de solicitud en curso de vuelta a OGK1.
Mar 4 15:31:20.286: RAS OUTGOING PDU ::= value RasMessage ::= requestInProgress : !--- The RIP message is sent back to !--- OGK1 since lrq-forward queries are configured on OGK2 and TGK2. { requestSeqNum 2048 delay 6000 } Mar 4 15:31:20.286: RAS OUTGOING ENCODE BUFFER::= 80 050007FF 176F Mar 4 15:31:20.286: Mar 4 15:31:20.286: IPSOCK_RAS_sendto: msg length 7 from 172.16.13.16:1719 to 172.16.13.35: 1719 Mar 4 15:31:20.286: RASLib::RASSendRIP: RIP (seq# 2048) sent to 172.16.13.35 Mar 4 15:31:20.286: H225 NONSTD OUTGOING PDU ::= value LRQnonStandardInfo ::= { ttl 4 nonstd-callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } callingOctet3a 128 gatewaySrcInfo { e164 : "4085272923", h323-ID : {"ogw"} } } Mar 4 15:31:20.290: H225 NONSTD OUTGOING ENCODE BUFFER::= 81 86B01100 221B686C 17CC11CC 8011A049 E0524766 01801002 048073B8 5A5C5640 02006F00 670077 Mar 4 15:31:20.290: Mar 4 15:31:20.290: PDU ::= value IZCToken ::= !--- The IZCT information. { izctInterZoneType interDomainCisco : NULL !--- The zone type is interDomain since the OGK2 !--- in a foreign domain is configured in TGK2. izctSrcZone "ogk2" !--- SrcZone is still ogk2. izctDstZone "tgk2" !--- DstZone changed to tgk2. } Mar 4 15:31:20.294: ENCODE BUFFER::= 47 20C06F67 6B320674 676B3204 73726304 64737404 696E74 Mar 4 15:31:20.294: Mar 4 15:31:20.294: RAS OUTGOING PDU ::= value RasMessage ::= locationRequest : !--- LRQ is sent to TGK1. { requestSeqNum 2048 destinationInfo { e164 : "3653" } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '8186B01100221B686C17CC11CC8011A049E05247...'H } replyAddress ipAddress : { ip 'AC100D23'H port 1719 } sourceInfo { h323-ID : {"ogk1"} } canMapAlias TRUE tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '4720C06F676B320674676B320473726304647374...'H } } } } Mar 4 15:31:20.302: RAS OUTGOING ENCODE BUFFER::= 4A 8007FF01 01806986 40B50000 12288186 B0110022 1B686C17 CC11CC80 11A049E0 52476601 80100204 8073B85A 5C564002 006F0067 007700AC 100D2306 B70BA00B 01400300 6F006700 6B003101 80300100 80092A86 4886F70C 0A010009 2A864886 F70C0A01 00184720 C06F676B 32067467 6B320473 72630464 73740469 6E74 Mar 4 15:31:20.306: Mar 4 15:31:20.306: IPSOCK_RAS_sendto: msg length 127 from 172.16.13.16:1719 to 172.16.13.41: 1719 Mar 4 15:31:20.306: RASLib::RASSendLRQ: LRQ (seq# 2048) sent to 172.16.13.41 -
-
Normalmente, TGK1 actualiza el dstCarrierID de IZCT al Carrier E, que viene determinado por el proceso de ruteo. Sin embargo, dado que no se utilizan portadoras, usted no ve eso. TGK1 genera un token hash con la contraseña de IZCT. Envía un LCF con el IZCT actualizado en él a OGK1. Este izctHash se utiliza para autenticar el ARQ answerCall que TGK1 recibe del TGW cuando éste recibe el mensaje de configuración VoIP del OGW.
Mar 4 15:31:20.351: PDU ::= value IZCToken ::= !--- IZCT with a hash is generated to be sent back to TGK2. { izctInterZoneType interDomainCisco : NULL izctSrcZone "ogk2" izctDstZone "tgk2" izctTimestamp 731259080 izctRandom 3 izctHash '5A7D5E18AA658A6A4B4709BA5ABEF2B9'H } Mar 4 15:31:20.355: ENCODE BUFFER::= 7F 20C06F67 6B320674 676B32C0 2B9620C7 0103105A 7D5E18AA 658A6A4B 4709BA5A BEF2B904 73726304 64737404 696E74 Mar 4 15:31:20.355: Mar 4 15:31:20.355: RAS OUTGOING PDU ::= value RasMessage ::= locationConfirm : !--- LCF is sent back to OGK1 since lrq-forward queries !--- are configured on OGK2 and TGK2. { requestSeqNum 2048 callSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } rasAddress ipAddress : { ip 'AC100D17'H port 55762 } nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '000140020074006700770600740067006B003101...'H } destinationType { gateway { protocol { voice : { supportedPrefixes { } } } } mc FALSE undefinedNode FALSE } tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } } Mar 4 15:31:20.367: RAS OUTGOING ENCODE BUFFER::= 4F 07FF00AC 100D1706 B800AC10 0D17D9D2 40B50000 122F0001 40020074 00670077 06007400 67006B00 31011001 40020074 00670077 00AC100D 1706B800 00000000 00000000 00104808 0880013C 05010000 48010080 092A8648 86F70C0A 0100092A 864886F7 0C0A0100 307F20C0 6F676B32 0674676B 32C02B96 20C70103 105A7D5E 18AA658A 6A4B4709 BA5ABEF2 B9047372 63046473 7404696E 74 Mar 4 15:31:20.371: Mar 4 15:31:20.371: IPSOCK_RAS_sendto: msg length 154 from 172.16.13.41:1719 to 172.16.13.35: 1719 Mar 4 15:31:20.371: RASLib::RASSendLCF: LCF (seq# 2048) sent to 172.16.13.35 -
OGK1 extrae el IZCT del LCF y lo envía en un ACF al OGW.
Mar 4 15:31:20.316: PDU ::= value IZCToken ::= !--- The extracted IZCT. { izctInterZoneType interDomainCisco : NULL izctSrcZone "ogk2" izctDstZone "tgk2" izctTimestamp 731259080 izctRandom 3 izctHash '5A7D5E18AA658A6A4B4709BA5ABEF2B9'H } Mar 4 15:31:20.324: ENCODE BUFFER::= 7F 20C06F67 6B320674 676B32C0 2B9620C7 0103105A 7D5E18AA 658A6A4B 4709BA5A BEF2B904 73726304 64737404 696E74 Mar 4 15:31:20.328: Mar 4 15:31:20.332: RAS OUTGOING PDU ::= value RasMessage ::= admissionConfirm : !--- ACF is sent back to OGW with the hashed IZCToken. { requestSeqNum 1109 bandWidth 640 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } irrFrequency 240 tokens !--- The IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } } Mar 4 15:31:20.352: RAS OUTGOING ENCODE BUFFER::= 2B 00045440 028000AC 100D1706 B800EF1A 08C04801 0080092A 864886F7 0C0A0100 092A8648 86F70C0A 0100307F 20C06F67 6B320674 676B32C0 2B9620C7 0103105A 7D5E18AA 658A6A4B 4709BA5A BEF2B904 73726304 64737404 696E7401 00020000 Mar 4 15:31:20.364: Mar 4 15:31:20.364: IPSOCK_RAS_sendto: msg length 97 from 172.16.13.35:1719 to 172.16.13.15: 57076 Mar 4 15:31:20.368: RASLib::RASSendACF: ACF (seq# 1109) sent to 172.16.13.15 -
El OGW envía el IZCT al TGW en el mensaje H.225 SETUP.
Mar 4 15:31:20.529: H225.0 OUTGOING PDU ::= value H323_UserInformation ::= { h323-uu-pdu { h323-message-body setup : !--- H.225 SETUP message is sent to TGW. { protocolIdentifier { 0 0 8 2250 0 2 } sourceAddress { h323-ID : {"ogw"} } sourceInfo { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } activeMC FALSE conferenceID '221B686C17CC11CC8010A049E0524766'H conferenceGoal create : NULL callType pointToPoint : NULL sourceCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11003 } callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } tokens !--- The hashed IZCT information is included in the setup message. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } fastStart { '0000000C6013800A04000100AC100D0F4125'H, '400000060401004C6013801114000100AC100D0F...'H } mediaWaitForConnect FALSE canOverlapSend FALSE } h245Tunneling TRUE nonStandardControl { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '6001020001041F04038090A31803A983816C0C21...'H } } } } -
El TGW pasa el IZCT al TGK1 en una contestación ARQcall.
Mar 4 15:31:20.613: Mar 4 15:31:20.613: RAS OUTGOING PDU ::= value RasMessage ::= admissionRequest : !--- ARQ answerCall type is sent to TGK1. { requestSeqNum 78 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"617D829000000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "4085272923", h323-ID : {"ogw"} } srcCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11003 } bandWidth 1280 callReferenceValue 3 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008800180'H } conferenceID '221B686C17CC11CC8010A049E0524766'H activeMC FALSE answerCall TRUE canMapAlias TRUE callIdentifier { guid '221B686C17CC11CC8011A049E0524766'H } tokens !--- The hashed IZCToken information is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B9620C7010310...'H } } } willSupplyUUIEs FALSE } -
TGK1 autentica el IZCT de destino con éxito. Esto se debe a que TGK1 genera el hash en IZCT y devuelve un ACF al TGW.
Mar 4 15:31:20.635: Mar 4 15:31:20.635: PDU ::= value IZCToken ::= !--- The extracted IZCT from the ARQ to be validated. { izctInterZoneType interDomainCisco : NULL izctSrcZone "ogk2" izctDstZone "tgk2" izctTimestamp 731259080 izctRandom 3 izctHash '5A7D5E18AA658A6A4B4709BA5ABEF2B9'H } Mar 4 15:31:20.639: RAS OUTGOING PDU ::= value RasMessage ::= admissionConfirm : !--- After the IZCT is validated, ACF is sent back to TGW. { requestSeqNum 78 bandWidth 1280 callModel direct : NULL destCallSignalAddress ipAddress : { ip 'AC100D17'H port 1720 } irrFrequency 240 willRespondToIRR FALSE uuiesRequested { setup FALSE callProceeding FALSE connect FALSE alerting FALSE information FALSE releaseComplete FALSE facility FALSE progress FALSE empty FALSE } } -
El TGW establece la llamada hacia la portadora D después de recibir el ACF.
Ejemplo 2: Error en la llamada porque TGW no puede extraer IZCT del mensaje de configuración recibido.
Este ejemplo se basa en la misma topología y configuración que el ejemplo 1. En este ejemplo, el software del TGW se cambia a una versión en la que no se admite IZCT. En tal caso, el TGW no puede extraer el IZCT del mensaje de configuración. Esto hace que TGK1 rechace la llamada con un motivo de desconexión de denegación de seguridad.
Este ejemplo muestra solamente el mensaje de configuración, ARQ, y ARJ en el TGW ya que el flujo de llamada es el mismo que el Ejemplo 1.
Mar 4 19:50:32.346: PDU DATA = 6147C2BC value H323_UserInformation ::= { h323-uu-pdu { h323-message-body setup : !--- H.225 SETUP message is received with a token included. { protocolIdentifier { 0 0 8 2250 0 2 } sourceAddress { h323-ID : {"ogw"} } sourceInfo { gateway { protocol { voice : { supportedPrefixes { { prefix e164 : "1#" } } } } } mc FALSE undefinedNode FALSE } activeMC FALSE conferenceID '56CA67C817F011CC8014A049E0524766'H conferenceGoal create : NULL callType pointToPoint : NULL sourceCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11004 } callIdentifier { guid '56CA67C817F011CC8015A049E0524766'H } tokens !--- Hashed IZCT is included. { { tokenOID { 1 2 840 113548 10 1 0 } nonStandard { nonStandardIdentifier { 1 2 840 113548 10 1 0 } data '7F20C06F676B320674676B32C02B965D85010410...'H } } } fastStart { '0000000C6013800A04000100AC100D0F45D9'H, '400000060401004C6013801114000100AC100D0F...'H } mediaWaitForConnect FALSE canOverlapSend FALSE } h245Tunneling TRUE nonStandardControl { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '6001020001041F04038090A31803A983816C0C21...'H } } } } RAW_BUFFER::= 60 01020001 041F0403 8090A318 03A98381 6C0C2180 34303835 32373239 32337005 80333635 33 Mar 4 19:50:32.362: PDU DATA = 6147F378 value H323_UU_NonStdInfo ::= { version 2 protoParam qsigNonStdInfo : { iei 4 rawMesg '04038090A31803A983816C0C2180343038353237...'H } } PDU DATA = 6147F378 value ARQnonStandardInfo ::= { sourceAlias { } sourceExtAlias { } callingOctet3a 128 } RAW_BUFFER::= 80 00000880 0180 Mar 4 19:50:32.366: PDU DATA = 6147C2BC value RasMessage ::= admissionRequest : !--- ARQ is sent out. There is no token in it. { requestSeqNum 23 callType pointToPoint : NULL callModel direct : NULL endpointIdentifier {"617D829000000001"} destinationInfo { e164 : "3653" } srcInfo { e164 : "4085272923" } srcCallSignalAddress ipAddress : { ip 'AC100D0F'H port 11004 } bandWidth 640 callReferenceValue 1 nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '80000008800180'H } conferenceID '56CA67C817F011CC8014A049E0524766'H activeMC FALSE answerCall TRUE canMapAlias FALSE callIdentifier { guid '56CA67C817F011CC8015A049E0524766'H } willSupplyUUIEs FALSE } RAW_BUFFER::= 27 98001600 F0003600 31003700 44003800 32003900 30003000 30003000 30003000 30003000 31010180 69860104 8073B85A 5C5600AC 100D0F2A FC400280 000140B5 00001207 80000008 80018056 CA67C817 F011CC80 14A049E0 52476644 E0200100 110056CA 67C817F0 11CC8015 A049E052 47660100 Mar 4 19:50:32.374: h323chan_dgram_send:Sent UDP msg. Bytes sent: 117 to 172.16.13.41:1719 Mar 4 19:50:32.374: RASLib::GW_RASSendARQ: ARQ (seq# 23) sent to 172.16.13.41 Mar 4 19:50:32.378: h323chan_dgram_recvdata:rcvd from [172.16.13.41:1719] on sock[1] RAW_BUFFER::= 2C 00168001 00 Mar 4 19:50:32.378: PDU DATA = 6147C2BC value RasMessage ::= admissionReject : !--- ARJ is received with a reason of security denial. { requestSeqNum 23 rejectReason securityDenial : NULL } Mar 4 19:50:32.378: ARJ (seq# 23) rcvd
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
22-Jan-2002 |
Versión inicial |
Comentarios