Gateway to Gatekeeper (H.235) and Gatekeeper to Gatekeeper (IZCT) Security Troubleshooting Guide

Atualizado:20 de fevereiro de 2019
ID do documento:18729

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introdução

As redes H.323 têm diferentes tipos de configurações e fluxos de chamada. Este documento discute a maioria das preocupações de segurança com redes H.323 que envolvem gatekeepers. Este documento resume a forma como cada recurso funciona e como solucioná-lo com uma explicação sobre a maioria das depurações. Este documento não aborda a segurança geral do VoIP.

Este documento aborda estes recursos:

  • Gateway Intradomínio para Segurança de Gatekeeper — Essa segurança é baseada no H.235, no qual as chamadas H.323 são autenticadas, autorizadas e roteadas por um gatekeeper. O gatekeeper é considerado uma entidade conhecida e confiável, no sentido de que o gateway não o autentica quando o gateway tenta se registrar nele.

  • Interdomain Gatekeeper to Gatekeeper Security — Essa segurança abrange a autenticação e a autorização de chamadas H.323 entre os domínios administrativos dos Internet Telephone Service Providers (ITSPs) usando InterZone Clear Token (IZCT). Este documento abrange somente a parte em que o gatekeeper de terminação envia um token em sua mensagem de confirmação de localização (LCF) para que ele autentique o answerCall Admission Request (ARQ). A validação da solicitação de local (LRQ) não está incluída neste recurso. A validação de LRQ é um recurso programado para uma futura versão do Cisco IOS® Software.

Definições

Acrônimo Definição
ARQ Solicitação de Admissão—Uma mensagem de Registro, Admissão e Protocolo de Status (RAS - Registration, Admission, and Status Protocol) enviada de um ponto final H.323 para um gatekeeper que solicita uma admissão para estabelecer uma chamada.
ACF Confirmação de Admissão—Uma mensagem RAS enviada do gatekeeper ao ponto final que confirma a aceitação de uma chamada.
ARJ Admission Rejection — Uma mensagem RAS do gatekeeper para o ponto final que rejeita a solicitação de admissão.
CAT Cisco Access Token—O Token Limpo H.235.
CHAP Challenge Handshake Authentication Protocol — Um protocolo de autenticação em que um desafio é usado.
GCF Gatekeeper Confirm—Uma mensagem RAS enviada de um gatekeeper para o ponto final H.323 que confirma a descoberta do gatekeeper.
GRQ Solicitação de gatekeeper—Uma mensagem RAS enviada de um ponto final H.323 para descobrir o gatekeeper.
H.235 Recomendação ITU para segurança e criptografia para terminais multimídia H-Series (H.323 e outros baseados em H.245).
IZCT InterZone Clear Token—Um IZCT é gerado no gatekeeper de origem quando um LRQ é iniciado ou um ACF está prestes a ser enviado para uma chamada de intrazona dentro do domínio administrativo ITSP.
LRQ Solicitação de local—Uma mensagem RAS enviada de um gatekeeper para o próximo gatekeeper de salto ou trecho de chamada para rastrear e rotear a chamada.
RAS Registro, Admissão e Status—Um protocolo que permite que um gatekeeper execute verificações de registro, admissão e status do ponto final.
RCF Registration Confirm—Uma mensagem RAS enviada do gatekeeper para o ponto final que confirma o registro.
RRJ Registration Reject — Uma mensagem RAS enviada do gatekeeper que rejeita a solicitação de registro.
RRQ Solicitação de registro—Uma mensagem RAS enviada do ponto final para o gatekeeper que solicita o registro com ele.
RIP Solicitação em andamento—Uma mensagem RAS enviada de um gatekeeper para o remetente que declara que a chamada está em andamento.

Gateway intradomínio para segurança do Gatekeeper

O H.323 é uma recomendação da ITU que trata da proteção da comunicação em tempo real em redes não seguras. Isso envolve duas grandes áreas de preocupação: autenticação e privacidade. Há dois tipos de autenticação, de acordo com o H.235:

  • Autenticação simétrica baseada em criptografia que não requer contato prévio entre as entidades de comunicação.

  • Com base na capacidade de ter algum segredo compartilhado anterior (mais conhecido como baseado em assinatura), duas formas de autenticação baseada em assinatura são fornecidas:

    • senha

    • certificado

Selo de tempo passado nos tokens

Um carimbo de data/hora é usado para evitar ataques de repetição. Por conseguinte, é necessário que haja uma referência à hora mutuamente aceitável (a partir da qual se devem derivar os carimbos de data/hora). A quantidade de desvio de tempo aceitável é uma questão de implementação local.

Como a Cisco implementa as recomendações de H.235

A Cisco usa um esquema de autenticação do tipo Challenge Handshake Authentication Protocol (CHAP) como base para sua implementação de gateway para seu gatekeeper H.235. Isso permite que você aproveite a Autenticação, Autorização e Tarifação (AAA - Authentication, Authorization, and Accounting), usando a funcionalidade existente para executar a autenticação real. Isso também significa que o gatekeeper não precisa ter acesso a um banco de dados de IDs de gateway, números de conta de usuário, senhas e PINs. O esquema é baseado no H.235, seção 10.3.3. É descrito como senha baseada em assinatura com hash.

No entanto, em vez de usar criptoTokens H.225, esse método usa clearTokens H.235 com campos preenchidos adequadamente para uso com o RADIUS. Esse token é conhecido como Cisco Access Token (CAT). Você sempre pode executar a autenticação localmente no gatekeeper em vez de usar um servidor RADIUS.

O uso de cryptoTokens requer que o gatekeeper mantenha ou tenha alguma forma de adquirir senhas para todos os usuários e gateways. Isso ocorre porque o campo de token do cryptoToken é especificado de tal forma que a entidade de autenticação precisa da senha para gerar seu próprio token em relação ao qual comparar o recebido.

Os gatekeepers Cisco ignoram completamente os cryptoTokens. No entanto, os gatekeepers do vocalTek e outros que suportam a seção 10.3.3 do H.235 usam os cryptoTokens para autenticar o gateway. Os gatekeepers Cisco usam o CAT para autenticar o gateway. Como o gateway não sabe com que tipo de gatekeeper ele se comunica, ele envia ambos no RRQ. O authenticationCapability no GRQ é para o cryptoToken e indica que o hash MD5 é o mecanismo de autenticação (embora o CAT também use MD5).

Consulte Cisco H.323 Gateway Security and Accounting Enhancements para obter mais informações.

Como configurar os níveis de segurança

  • Segurança no nível de endpoint ou registro

    Com a segurança de registro ativada no gatekeeper, o gateway é necessário para incluir um CAT em todas as mensagens RRQ de peso pesado. O CAT, nesse caso, contém informações que autenticam o próprio gateway para o gatekeeper. O gatekeeper formata uma mensagem para um servidor RADIUS que autentica as informações contidas no token. Ele responde de volta ao gatekeeper com um Access-Accept ou Access-Reject. Isso, por sua vez, responde ao gateway com um RCF ou um RRJ.

    Se uma chamada for feita a partir de um gateway autenticado com êxito, esse gateway gera um novo CAT no recebimento de um ACF do gatekeeper usando a senha do gateway. Este CAT é idêntico ao gerado durante o registro, exceto para o carimbo de data e hora. Ele é colocado na mensagem SETUP de saída. O gateway de destino extrai o token da mensagem SETUP e o coloca no ARQ do lado de destino. O gatekeeper usa o RADIUS para autenticar o gateway de origem antes de enviar o ACF do lado de destino. Isso impede que um endpoint não autenticado que conheça o endereço de um gateway o utilize para contornar o esquema de segurança e acessar a rede telefônica pública comutada (PSTN).

    Portanto, nesse nível, não há necessidade de incluir nenhum token nos ARQs de origem.

    Digite [no] security token required-for registration na interface de linha de comando (CLI) do gatekeeper para configurá-lo. A opção no do comando faz com que o gatekeeper não verifique mais tokens em mensagens RAS.

    Digite [no] security password <PASSWORD> level endpoint na CLI do gateway para configurar o gateway. A opção no do comando faz com que o gateway não gere mais tokens para mensagens RAS.

  • Segurança de nível por chamada

    A segurança por chamada baseia-se na segurança no nível do registro. Além de atender aos requisitos de segurança de registro, um gateway também é necessário para incluir tokens de acesso em todas as mensagens ARQ laterais de origem quando a segurança por chamada está habilitada no gatekeeper. O token, nesse caso, contém informações que identificam o usuário do gateway para o gatekeeper. Essas informações são obtidas com o uso de um script de Resposta de Voz Interativa (IVR) no gateway. Isso solicita que os usuários insiram sua ID de usuário e PIN no teclado antes de fazer uma chamada.

    O CAT contido no ARQ de origem é autenticado pelo RADIUS da mesma forma descrita anteriormente em Endpoint- or Registration-level Security. Depois de receber o ACF, o gateway gera um novo CAT usando sua senha e o envia na mensagem SETUP H.225 para o gateway de terminação.

    Digite [no] security token required-for all na CLI do gatekeeper para configurar o gatekeeper. A opção no do comando faz com que o gatekeeper não verifique mais tokens em mensagens RAS.

    Digite [no] security password <PASSWORD> level per-call na CLI do gateway para configurar o gateway. A opção no do comando faz com que o gateway não gere mais tokens para mensagens RAS.

  • Segurança de todos os níveis

    Isso permite que o gateway inclua um CAT em todas as mensagens de RAS necessárias para registro e para chamadas. Portanto, é uma combinação dos dois níveis acima. Com essa opção, a validação de mensagens CAT in ARQ é baseada no número da conta e no PIN do usuário que faz uma chamada. A validação do CAT enviado em todas as outras mensagens de RAS é baseada na senha configurada para o gateway. Portanto, é semelhante ao nível Por chamada.

    Digite [no] security token required-for all na CLI do gatekeeper para configurar o gatekeeper. A opção no do comando faz com que o gatekeeper não verifique mais tokens em mensagens RAS.

    Digite [no] security password <PASSWORD> level all na CLI do gateway para configurar o gateway. A opção no do comando faz com que o gateway não gere mais tokens para mensagens RAS.

Uso de H235 em um nível por chamada sem IVR

O H.235 não pode ser usado em um nível por chamada sem IVR. Se não houver IVR para coletar uma conta e PIN, o gateway precisará enviar o ARQ sem um token de limpeza (mas com um token de criptografia). Como o gatekeeper Cisco aceita somente tokens claros, a chamada é rejeitada pelo gatekeeper com um motivo de negação de segurança.

Este exemplo mostra as depurações h225 asn1 coletadas de um gateway de origem (OGW) que não está configurado para uma IVR coletar a conta e o PIN. A mensagem RRQ tem um token limpo, mas o ARQ não. Uma mensagem ARJ é enviada de volta ao 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

Problemas principais

Os principais problemas com os quais você precisa se preocupar incluem:

  • Configuração do gateway e do gatekeeper

  • Configuração do RADIUS no gatekeeper e no servidor RADIUS

  • Network Time Protocol (NTP)—Você deve ter o mesmo horário em todos os gateways e gatekeepers. Como as informações de autenticação incluem um carimbo de data/hora, é importante que todos os gateways Cisco H.323 e os gatekeepers (ou outra entidade que executa a autenticação) sejam sincronizados. Os gateways Cisco H.323 devem ser sincronizados usando o NTP.

  • Falha de software devido a um bug

Depurações e fluxo de chamada para níveis diferentes

Como a segurança de todos os níveis cobre casos de registro e por chamada, o laboratório é configurado com esse nível de segurança para este exercício. Os fluxos de chamada para a parte de registro e uma chamada VoIP normal são explicados na configuração aqui.

Observação: a configuração aqui não está completa. Seguem-se mais comandos entre as saídas de depuração. Ele foi projetado para mostrar que problema pode acontecer se você não verificar todos os itens, como configuração, NTP e RADIUS. Além disso, o gateway é autenticado localmente no gatekeeper para que você possa ver quais valores estão definidos para a ID e a senha do gateway. Esta configuração é cortada para que somente a configuração relacionada seja exibida.

!
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 depurações estão ativadas neste exemplo:

A primeira coisa que ocorre é que o gateway envia um GRQ ao gatekeeper e o gatekeeper envia um GCF para o gateway. Em seguida, o gateway envia um RRQ e espera por um RCF ou RRJ.

Na configuração anterior, o gateway não está definido para qualquer nível de segurança, de modo que seu GRQ não transporta authenticationCapability que é necessário para os tokens. No entanto, o gatekeeper ainda envia de volta um GCF como mostra esta saída: 

*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 }
   }
  }

Isso explica algumas das mensagens no GRQ:

  • authenticationCapability — Este campo tem apenas o valor de pwdHash. Indica que o hash MD5 é o mecanismo de autenticação.

  • algorithmOIDs — O ID de objeto do algoritmo. Nesse caso, ele transporta o valor (1 2 840 113549 2 5) que é a ID de objeto para o hash Message Digest 5.

    (1 2 840 113549 2 5) traduz para iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) md5(5). Portanto, a Cisco faz o hash de senha MD5.

    Rsadsi significa RSA data security Inc. O identificador de objeto Open Systems Interconnection (OSI) da RSA Data Security, Inc. é 1.2.840.113549 (0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d em hex), conforme registrado pelo American National Standards Institute (ANSI).

O gatekeeper envia novamente um GCF como a mensagem anterior. Em seguida, o gateway envia uma RRQ com determinados campos para descrever os tokens que ele usa para ser autenticado. A mensagem asn1 RRQ enviada é mostrada neste exemplo. 

*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 da resposta ser discutida, alguns dos campos relacionados na mensagem RRQ acima são explicados aqui. Há dois tipos de tokens: um token limpo ou CAT) e um token de criptografia.

Como mencionado antes, os gatekeepers Cisco ignoram os tokens de criptografia. No entanto, o gateway ainda envia ambos porque não sabe para que tipo de gatekeeper ele está falando. Como outros fornecedores podem usar criptotototokens, o gateway envia ambos.

Isso explica a sintaxe ClearToken.

  • tokenOID — A ID do objeto para identificar o token.

  • timeStamp — A hora UTC (Coordinated Universal Time, Tempo Universal Coordenado) atual do gateway. Segundos desde 00:00 1/1/1970 UTC.

    É usado como um CHAP-Desafio implícito como se tivesse vindo inicialmente do gatekeeper.

  • challenge—Um resumo de mensagem MD5 de 16 bytes gerado pelo gateway usando estes campos:

    challenge = [ random + GW/User Password + timeStamp ] Hash MD5

    O RADIUS executa esse cálculo (já que ele sabe o número aleatório, a senha do gateway e o desafio CHAP) para determinar qual deve ser o desafio: Resposta CHAP = [ CHAP ID + UserPassword + CHAP Challenge ] MD5 Hash

  • random — Um valor de um byte usado pelo RADIUS para identificar essa solicitação específica.

    O gateway incrementa um módulo variável de 256 para cada solicitação de autenticação para satisfazer esse requisito RADIUS.

  • generalID — O gateway H323-ID ou o número da conta do usuário com base no nível de segurança e no tipo de mensagem RAS.

Observação: todos esses campos são importantes. No entanto, mais atenção é dada ao carimbo de data e hora e ao generalID. Nesse caso, o carimbo de data/hora é 731030839 e o generalID é gwa-1@cisco.com.

O cryptoToken no RRQ contém informações sobre o gateway que gera o token. Isso inclui o ID do gateway (que é o ID H.323 configurado no gateway) e a senha do gateway.

Este campo contém um dos tipos cryptoToken definidos para o campo CryptoH323Token especificado em H.225. Atualmente, o único tipo de cryptoToken suportado é o cryptoEPPwdHash.

Esses campos estão contidos no campo cryptoEPPwdHash:

  • alias — O alias do gateway, que é o ID H.323 do gateway.

  • timestamp — O timestamp atual.

  • token — O PwdCertToken codificado no Message Digest 5 (MD5). Este campo contém estes itens:

    • timestamp — O mesmo que o timestamp do cryptoEPPwdHash.

    • password — A senha do gateway.

    • generalID — O mesmo alias de gateway que o incluído em cryptoEPPwdHash.

    • tokenID — A ID do objeto.

Exiba a resposta do gatekeeper neste exemplo.

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

O RRQ é rejeitado pelo gatekeeper. A razão para isso é porque não havia nenhum NTP definido na configuração do gateway. O gatekeeper verifica o carimbo de data/hora do token para ver se ele está dentro de uma janela aceitável em relação ao seu próprio tempo. Atualmente, essa janela está +/- 30 segundos em torno da hora UTC do gatekeeper.

Um token fora dessa janela faz com que o gatekeeper descarte essa mensagem. Isso evita ataques de repetição de alguém que tenta reutilizar um token rastreado. Na prática, todos os gateways e gatekeepers precisam usar o NTP para evitar esse problema de desvio de tempo. O gatekeeper descobre que o carimbo de data/hora no token está dentro da janela aceitável de seu tempo. Portanto, ele não verifica com o RADIUS para autenticar o gateway.

Em seguida, o gateway é configurado para NTP apontando para o gatekeeper como o NTP mestre, de modo que o gateway e o gatekeeper tenham o mesmo tempo. Quando isso ocorre, o gateway envia um novo RRQ e desta vez o gatekeeper responde de volta ao novo RRQ com um RRJ.

Essas depurações são do gatekeeper. As depurações são executadas para ver se o gatekeeper vai para a fase de autenticação. 

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"}
  }

Depois de configurar o NTP, o gatekeeper ainda rejeita o RRQ. Desta vez, no entanto, ele passa pelo processo de autenticação para esse gateway. O gatekeeper rejeita a RRQ porque o usuário (aqui a ID do gateway) não é encontrado na lista de usuários válidos no RADIUS. O gateway é autenticado localmente na configuração do gatekeeper. Na lista de usuários, você vê gwa-1. No entanto, esse não é o usuário correto, pois o usuário no RRQ é gwa-1@cisco.com.

Além disso, depois que o comando username gwa-1@cisco.com password 0 2222 é configurado no gatekeeper, o gatekeeper confirma o RRQ e o gateway é registrado.

Neste laboratório, outro gateway (gwa-2) está registrado no mesmo gatekeeper (gka-1). Uma chamada é feita de gwa-1@cisco.com para gwa-2 para ver a aparência do ARQ, ACF e das mensagens de configuração.

Essas depurações coletadas são do gateway de origem e de terminação (gwa-2).

Uma explicação de algumas das mensagens de depuração está incluída.

Antes de imprimir as depurações do gateway de origem/término, este texto explica o fluxo de chamadas:

  1. Quando uma mensagem SETUP é recebida do PSTN, o gateway envia um ARQ para o gatekeeper e recebe um ACF dele.

  2. Quando o gateway recebe o ACF, ele gera um CAT usando a senha do gateway, o alias H323-ID e a hora atual. O token é colocado no Bloco de controle de chamadas (CCB).

  3. Quando o gateway envia a mensagem SETUP ao gateway de terminação, ele recupera o token de acesso do CCB e o coloca no campo nonStandardParameter de um clearToken dentro da mensagem SETUP.

  4. O gateway de terminação remove o token da mensagem SETUP, converte-o de um nonStandardParameter em um CAT e o coloca no ARQ.

  5. O gatekeeper verifica o carimbo de data/hora do token para ver se ele está dentro de uma janela aceitável em relação ao seu próprio tempo. Atualmente, essa janela está +/- 30 segundos em torno da hora UTC do gatekeeper. Um token fora dessa janela faz com que o gatekeeper descarte essa mensagem. Isso faz com que a chamada seja rejeitada.

  6. Se o token for aceitável, o gatekeeper formatará um pacote de solicitação de acesso RADIUS, preencherá os atributos apropriados para verificar um desafio de CHAP e o enviará a um servidor RADIUS.

  7. Com base na suposição de que o alias do gateway é conhecido no servidor, o servidor localiza a senha associada a esse alias e gera sua própria resposta CHAP usando o alias, a senha e o desafio CHAP do gatekeeper. Se sua resposta CHAP corresponder à recebida do gatekeeper, o servidor enviará um pacote de aceitação de acesso para o gatekeeper. Se eles não corresponderem ou se o alias do gateway não estiver no banco de dados do servidor, o servidor enviará um pacote de Rejeição de Acesso de volta ao gatekeeper.

  8. O gatekeeper responde ao gateway com um ACF se receber um Access Accept, ou um ARJ com o código de causa securityDenial se receber um Access Reject. Se o gateway receber um ACF, a chamada será conectada.

Este exemplo mostra a depuração do gateway de origem.

Observação: as depurações h225 asn1 para a configuração não estão neste exemplo, pois são as mesmas do exemplo do gateway de terminação que segue o exemplo do gateway de origem.

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 exemplo mostra as depurações do gateway de terminação (TGW). Observe que o TGW configurou o segundo segmento desde que obteve ACF e a chamada 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)

Problema de IOS do gateway

No mesmo laboratório, a imagem do IOS 12.2(6a) é carregada no OGW. Quando uma chamada é feita, percebe-se que o OGW ainda envia um Clear Token baseado em sua senha, mesmo que o gateway não esteja configurado para IVR para coletar a Conta/PIN. Além disso, o gatekeeper configurado para o nível de chamada aceita essa chamada. Isso está documentado no bug da Cisco ID CSCdw43224 (somente clientes registrados) .

Segurança com pontos finais alternativos

Como mencionado anteriormente neste documento, a segurança de chamada de ponta a ponta é fornecida com o uso de tokens de acesso que são enviados no campo clearTokens nas mensagens RAS/H.225. Ao habilitar essa segurança, o gateway de origem encaminha o token de acesso recebido do gatekeeper em um ACF para o ponto final H.323 de destino na mensagem SETUP H.225. Esse ponto final H.323 de destino encaminha o token de acesso recebido na mensagem SETUP para o gatekeeper em sua solicitação de admissão. Ao fazer isso, ele dá ao gatekeeper remoto a capacidade de aceitar chamadas com base na validade do token de acesso. O conteúdo do token de acesso depende da entidade que o gera. Para minimizar as brechas de segurança e proteger contra ataques man-in-the-middle, os gatekeepers podem codificar informações específicas de destino no token de acesso. Isso significa que quando alternateEndpoints são fornecidos em um ACF, o gatekeeper pode fornecer um token de acesso separado para cada alternateEndpoint especificado.

Quando ele tenta estabelecer uma conexão pela primeira vez, o gateway Cisco envia o token de acesso que recebeu no campo clearToken do ACF com o endereço no campo destCallSignalAddress. Se essa tentativa não for bem-sucedida e o gateway da Cisco continuar tentando conexões com um ponto final alternativo, ele usará o token de acesso associado (se estiver disponível) da lista de pontos finais alternativos. Se a lista alternateEndpoints recebida no ACF não incluir tokens de acesso, mas o ACF incluir um token de acesso, o gateway da Cisco incluirá esse token de acesso em todas as tentativas de conexão com um endpoint alternativo.

Suporte a OSP Token

Atualmente, o Open Settlement Protocol (OSP) e seus tokens são suportados apenas nos gateways da Cisco. Não há suporte no gatekeeper. O gateway reconhece os tokens OSP recebidos de um servidor de liquidação e os insere na mensagem de configuração Q.931 para um gateway de terminação.

Níveis diferentes de segurança de cada ponto final ou zona

No momento, você não pode configurar diferentes níveis de segurança para cada endpoint ou zona. O nível de segurança é para todas as zonas gerenciadas por esse gatekeeper. Uma solicitação de recurso pode ser aberta em razão desse problema.

Gatekeeper interdomínio para segurança do gatekeeper

A segurança de gatekeeper entre domínios para gatekeeper fornece a capacidade de validar solicitações intradomínio e entre domínios de gatekeeper para gatekeeper por salto. Isso significa que o gatekeeper de destino encerra o CAT e gera um novo se o gatekeeper decidir encaminhar o LRQ adiante. Se o gatekeeper detectar uma assinatura de LRQ inválida, ele responderá enviando um Location Reject (LRJ).

Implementar gatekeeper para segurança de gatekeeper

O gatekeeper de origem gera um IZCT quando um LRQ é iniciado ou um ACF está prestes a ser enviado no caso de uma chamada entre zonas. Esse token é atravessado por seu caminho de roteamento. Ao longo do caminho, cada gatekeeper atualiza o ID do gatekeeper de destino e/ou o ID do gatekeeper de origem, se necessário, para refletir as informações de zona. O gatekeeper de terminação gera um token com sua senha. Esse token é devolvido nas mensagens de confirmação de local (LCF) e passado para o OGW. O OGW inclui esse token na mensagem SETUP H.225. Quando o TGW recebe o token, ele é encaminhado na chamada de resposta ARQ e validado pelo gatekeeper de terminação (TGK) sem qualquer necessidade de um servidor RADIUS.

O tipo de autenticação é baseado em senha com hash, conforme descrito no ITU H.235. Especificamente, o método de criptografia é MD5 com hash de senha.

A finalidade do IZCT é saber se o LRQ chegou de um domínio estrangeiro, de qual zona e de qual portadora. Ele também é usado para passar um token do TGK para o OGW no LCF. No formato IZCT, estas informações são necessárias:

  • srcCarrierID — Identificação da transportadora de origem

  • dstCarrierID — Identificação da transportadora de destino

  • intCarrierID — Identificação de portadora intermediária

  • srcZone — Zona de origem

  • dstZone — Zona de destino

  • tipo interzona

    • INTRA_DOMAIN_CISCO

    • INTER_DOMAIN_CISCO

    • INTRA_DOMAIN_TERM_NOT_CISCO

    • INTER_DOMAIN_ORIG_NOT_CISCO

Esse recurso funciona bem sem a necessidade de uma ID de portadora do gateway ou de um servidor de Roteamento sensível à portadora (CSR). Nesse caso, os campos sobre a ID da transportadora estarão vazios. Os exemplos aqui não incluem nenhuma ID de portadora. Para obter um fluxo de chamadas detalhado, suporte de versão e plataforma e configurações, consulte Aprimoramento de segurança do gatekeeper interdomínio.

Configuração de gatekeeper

O recurso IZCT requer essa configuração no gatekeeper. 

Router(gk-config)#
[no] security izct password

A senha precisa ter de seis a oito caracteres. Identifique qual zona está em um domínio 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]

Fluxo de chamada IZCT

Este diagrama mostra o fluxo de IZCT.

gw_security.gif

Nessa configuração, os nomes dos gateways e gatekeepers são os mesmos usados no diagrama de fluxo de chamadas do IZCT, mas com letras minúsculas. O fluxo de chamadas é explicado após a configuração, com explicações de depuração.

Para explicar o recurso IZCT e o fluxo de chamadas, o primeiro exemplo não tem o gateway intradomínio para a segurança do gatekeeper. Depois disso, há exemplos em que o TGW não pode gerar o IZCT de modo que o TGK1 rejeite a chamada. Isso serve para mostrar que o recurso funciona como projetado. Todas essas configurações são baseadas na topologia do diagrama de fluxo de chamadas IZCT.

Exemplo 1: Fluxo de chamadas somente para segurança de gatekeeper para gatekeeper

Este exemplo mostra as configurações relacionadas de todos os gateways e gatekeepers.

Configuração do OGW Configuração do 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

Configuração do OGK1 Configuração do 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

Configuração OGK2 Configuração 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

Fluxo de chamada com depurações

Esses exemplos usam as depurações para explicar o fluxo de chamadas.

  1. Um usuário na operadora E chama um usuário na operadora 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)

  2. Como o dialpeer do gateway de origem (tag=3653) está configurado para RAS, ele envia um ARQ para 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

  3. Quando OGK1 recebe o ARQ, ele determina que o destino é atendido pela zona remota OGK2. Em seguida, ele identifica que um IZCT é necessário ( através da CLI: security izct password <pwd>). OGK1 continua a criar o IZCT antes que o LRQ seja enviado. Em seguida, ele envia o IZCT e o LRQ para OGK2 e envia uma mensagem RIP de volta para 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

  4. Quando OGK2 recebe o LRQ, ele verifica o IZCT. A partir da configuração, ele descobre que o LRQ também precisa conter um IZCT. O OGK2 cria um novo IZCT alterando izctSrcZone e izctDstZone para ogk2 e encaminha o LRQ para TGK2. Depois de enviar o LRQ para TGK2, ele retorna uma mensagem RIP para OGK1.

    Se os gatekeepers fizerem parte de um cluster, o nome do cluster será usado para SrcZone ou 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

  5. O TGK2 determina que o LRQ vem de um domínio estrangeiro. Ele atualiza a dstZone do IZCT com sua própria ID e interZoneType como INTER_DOMAIN_CISCO. Em seguida, cria um novo CAT e passa o IZCT atualizado e o LRQ para TGK1.

    O TGK2 trata a zona da qual um LRQ é recebido como uma zona de domínio externo em um destes dois cenários:

    • A lista de zonas remotas do TGK2 não contém a zona da qual um LRQ é recebido.

    • A lista de zonas remotas do TGK2 contém a zona da qual um LRQ é recebido. A região é marcada com um sinalizador de domínio externo.

    Em seguida, ele envia uma mensagem Request In Progress (Solicitação em andamento) de volta para 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

  6. Normalmente, o TGK1 atualiza o dstCarrierID do IZCT para a Portadora E, que é determinada pelo processo de roteamento. No entanto, como nenhuma portadora é usada, você não vê isso. O TGK1 gera um token de hash com a senha do IZCT. Ele envia um LCF com o IZCT atualizado para OGK1. Esse izctHash é usado para autenticar o answerCall ARQ que o TGK1 recebe do TGW quando o usuário recebe a mensagem de configuração de VoIP do 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

  7. O OGK1 extrai o IZCT do LCF e o envia em um ACF para o 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

  8. O OGW envia o IZCT para o TGW na mensagem 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
    }
   }
  }
 }

  9. O TGW passa o IZCT para o TGK1 em uma answerCall ARQ. 

    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
  }

  10. O TGK1 autentica o IZCT de destino com êxito. Isso ocorre porque o TGK1 gera o hash no IZCT e envia de volta um ACF para o 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
   }
  }

  11. O TGW estabelece a chamada em direção à Portadora D depois que ela recebe o ACF.

    Exemplo 2: Falha na chamada porque o TGW não pode extrair o IZCT da mensagem de instalação recebida.

    Este exemplo é baseado na mesma topologia e configuração do Exemplo 1. Neste exemplo, o software do TGW é alterado para uma versão em que o IZCT não é suportado. Nesse caso, o TGW não pode extrair o IZCT da mensagem de configuração. Isso faz com que o TGK1 rejeite a chamada com um motivo de desconexão de negação de segurança.

    Este exemplo mostra apenas a mensagem de configuração, ARQ e ARJ no TGW, já que o fluxo de chamada é o mesmo do Exemplo 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

Informações Relacionadas

Histórico de revisões

Revisão Data de publicação Comentários
1.0
22-Jan-2002
Versão inicial

Colaboração de

  • nhaddad
    ctrieu

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco