ゲートウェイからゲートキーパー（H.235）およびゲートキーパーからゲートキーパー（IZCT）へのセキュリティのトラブルシューティングガイド

Updated: 2019 年 2 月 20 日

Document ID:18729

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

H.323 ネットワークには、さまざまな種類の設定およびコールフローがあります。このドキュメントでは、ゲートキーパーを含む H.323 ネットワークのセキュリティ上の問題について説明します。このドキュメントでは、各機能の仕組みを概説し、トラブルシューティングの方法と大半のデバッグの説明を示します。このドキュメントでは、VoIP のセキュリティについては説明しません。

このドキュメントでは、次の機能を扱っています。

イントラドメインのゲートウェイからゲートキーパーへのセキュリティ：このセキュリティは、H.235 に基づきます。その場合、H.323 コールは、ゲートキーパーによって、認証、認可、ルーティングされます。ゲートキーパーは、ゲートウェイがゲートキーパーに登録しようとするときに、ゲートウェイによる認証がないという意味で、既知で信頼できるエンティティであると見なされます。
ドメイン間のゲートキーパー間のセキュリティ：このセキュリティでは、InterZone Clear Token（IZCT）を使用して、インターネット電話サービスプロバイダー（ITSP）の管理ドメイン間の H.323 コールの認証および許可を扱います。このドキュメントでは、着信側ゲートキーパーで、answerCall アドミッション要求（ARQ）を認証できるように、ロケーション確認（LCF）メッセージにトークンを入れて送信する部分だけを扱います。ロケーション要求（LRQ）の検証は、この機能に含まれません。LRQ の検証は、将来の Cisco IOS® ソフトウェアリリースで対応予定の機能です。

定義

略語	定義
ARQ	Admission Request（アドミッション要求）：コール確立のアドミッションを要求するために、H.323 エンドポイントからゲートキーパーに送信される Registration, Admission, and Status Protocol（RAS）メッセージ。
ACF	Admission Confirm（アドミッション確認）：ゲートキーパーからエンドポイントに送信される RAS メッセージ。コールの受け入れを確認します。
ARJ	Admission Rejection（アドミッション拒否）：ゲートキーパーからエンドポイントに送られる RAS メッセージ。アドミッション要求を拒否します。
CAT	Cisco Access Token：H.235 Clear Token。
CHAP	Challenge Handshake Authentication Protocol（チャレンジハンドシェイク認証プロトコル）：チャレンジを使用する認証プロトコル。
GCF	Gatekeeper Confirm（ゲートキーパー確認）：ゲートキーパーから H.323 エンドポイントに送られる RAS メッセージ。ゲートキーパーの検出を確認します。
GRQ	Gatekeeper Request（ゲートキーパー要求）：ゲートキーパーを検出するために H.323 エンドポイントから送信される RAS メッセージ。
H.235	H シリーズ（H.323 およびその他の H.245 ベースの）マルチメディア端末に対するセキュリティおよび暗号化に関する ITU 勧告。
IZCT	InterZone Clear Token：IZCT は、LRQ が開始されるときか、ITSP 管理ドメイン内のイントラゾーンコールのために ACF が送信されようとするときに、発信側ゲートキーパーに生成されます。
LRQ	Location Request（ロケーション要求）：コールをトレースおよびルーティングするために、ゲートキーパーからネクストホップゲートキーパーまたはコールレッグに送信される RAS メッセージ。
RAS	Registration, Admission, and Status：ゲートキーパーによるエンドポイントの登録、アドミッション、およびステータスチェックの実行を可能にするプロトコル。
RCF	Registration Confirm：ゲートキーパーからエンドポイントに送られる RAS メッセージ。登録を確認します。
RRJ	Registration Reject：登録要求を拒否するためにゲートキーパーから送信される RAS メッセージ。
RRQ	Registration Request：エンドポイントからゲートキーパーに送信される RAS メッセージ。ゲートキーパーへの登録を要求します。
RIP	Request In Progress：コールが進行中であることを示す、ゲートキーパーから送信元に送信される RAS メッセージ。

イントラドメインのゲートウェイからゲートキーパーへのセキュリティ

H.323 は、保護されていないネットワーク越しのリアルタイム通信の保護を扱う、ITU 勧告です。次の 2 点が主な懸念になります。認証とプライバシーH.235 に従う 2 タイプの認証があります。

通信エンティティ間の事前接触を必要としない、対称暗号化ベース認証。
事前に持つことのできる共有秘密に基づいて（以後、サブスクリプションベース）、2 つの形式のサブスクリプションベース認証があります。
- password
- 証明書

トークンで渡されたタイムスタンプ

リプレイアタックを防ぐために、タイムスタンプが使用されます。したがって、相互に許容可能な時刻基準（タイムスタンプの導出元）が必要になります。許容可能な時間のずれの量は、ローカル実装に関する事項です。

シスコによる H.235 勧告の実装方法

シスコでは、チャレンジハンドシェイク認証プロトコル（CHAP）に似た認証スキームをゲートウェイからゲートキーパーへの H.235 実装の基礎として使用しています。これにより、認証、認可、アカウンティング（AAA）を利用し、既存の機能を使用して、実際の認証を実行できます。これは、ゲートウェイ ID、ユーザアカウント番号、パスワード、および PIN のデータベースに、ゲートキーパーがアクセスする必要のないことも意味します。この方式は、H.235のセクション10.3.3に基づいています。これは、ハッシュを使用したサブスクリプションベースのパスワードとして説明されています。

ただし、この方式では、H.225 cryptoToken の代わりに、RADIUS と連携するためにフィールドを適切に設定した H.235 clearToken を使用します。このトークンを Cisco Access Token（CAT）と呼びます。 RADIUS サーバを使用する代わりに、ゲートキーパーローカルで認証を常時実行できます。

cryptoToken を使用するには、ゲートキーパーで、すべてのユーザおよびゲートウェイのパスワードを保持するか、何らかの手段によって取得する必要があります。これは、認証側のエンティティでは、受信したトークンと比較する独自のトークンを生成するためのパスワードを必要とすることを踏まえて、cryptoToken のトークンフィールドを指定するためです。

Cisco ゲートキーパーでは、cryptoToken を完全に無視します。ただし、H.235 の 10.3.3 項をサポートしている vocalTek などのゲートキーパーでは、cryptoToken を使用してゲートウェイを認証します。Cisco ゲートキーパーでは、CAT を使用してゲートウェイを認証します。ゲートウェイでは、通信先のゲートキーパーのタイプを認識していないため、両方を RRQ に入れて送信します。GRQ の authenticationCapability は、cryptoToken 用であり、MD5 ハッシングを認証メカニズムとすることを示します（ただし、CAT でも MD5 を使用）。

詳細については、『Cisco H.323 ゲートウェイに関するアカウンティングおよびセキュリティの拡張』を参照してください。

セキュリティレベルの設定方法

エンドポイントレベルまたは登録レベルのセキュリティ

ゲートキーパーで登録セキュリティを有効にしてある場合、ゲートウェイでは、すべてのヘビーウェイトの RRQ メッセージに CAT を含める必要があります。この場合、CAT には、ゲートウェイ自体をゲートキーパーに対して認証する情報が含まれています。ゲートキーパーでは、トークンに含まれている情報を認証する RADIUS サーバに合わせてメッセージをフォーマットします。RADIUS サーバは、Access-Accept と Access-Reject のいずれかでゲートキーパーに応答します。これは、次に、RCF と RRJ のいずれかによるゲートウェイへの応答になります。

次に、正常に認証されたゲートウェイからコールが発信される場合、このゲートウェイでは、ゲートキーパーから ACF を受信したときに、ゲートウェイパスワードを使用して新しい CAT を生成します。この CAT は、タイムスタンプを除き、登録時に生成される CAT と同一です。これは、発信 SETUP メッセージに組み込まれます。宛先ゲートウェイでは、SETUP メッセージからトークンを抽出し、宛先側の ARQ に組み込みます。ゲートキーパーでは、RADIUS を使用して発信側ゲートウェイを認証してから、宛先側 ACF を送信します。これにより、ゲートウェイのアドレスを得ている、認証されていないエンドポイントが、このアドレスを使用してセキュリティスキームを迂回し、公衆電話交換網（PSTN）にアクセスすることを防ぎます。

したがって、このレベルでは、発信側 ARQ にトークンを含める必要はありません。

ゲートキーパーのコマンドラインインターフェイス（CLI）から [no] security token required-for registration と入力して、ゲートキーパーを設定します。このコマンドの no オプションを使用した場合、ゲートキーパーは、RAS メッセージ内のトークンをチェックしなくなります。

ゲートウェイ CLI から [no] security password <PASSWORD> level endpoint と入力して、ゲートウェイを設定します。このコマンドの no オプションを使用した場合、ゲートウェイは、RAS メッセージ用のトークンを生成しなくなります。
コールごとレベルのセキュリティ

コールごとのセキュリティは、登録レベルのセキュリティ上に構築されます。コールごとのセキュリティがゲートキーパーで有効に設定されている場合、ゲートウェイでは、登録セキュリティ要件を満たすだけでなく、すべての発信側 ARQ メッセージにアクセストークンを組み込む必要もあります。この場合、トークンには、ゲートウェイのユーザをゲートキーパーに対して識別する情報が含まれています。この情報は、ゲートウェイ上の音声自動応答装置（IVR）スクリプトを使用して取得されます。これにより、ユーザは、コールを発信する前にキーパッドからユーザ ID および PIN を入力するように要求されます。

発信側 ARQ に含まれている CAT は、エンドポイントレベルまたは登録レベルのセキュリティですでに説明した方法と同じ方法で、RADIUS によって認証されます。ACF を受信したゲートウェイでは、ゲートウェイのパスワードを使用して新しい CAT を生成し、H.225 SETUP メッセージに組み込んで着信側ゲートウェイに送信します。

ゲートキーパーの CLI から [no] security token required-for all と入力して、ゲートキーパーを設定します。このコマンドの no オプションを使用した場合、ゲートキーパーは、RAS メッセージ内のトークンをチェックしなくなります。

ゲートウェイ CLI から [no] security password <PASSWORD> level per-call と入力して、ゲートウェイを設定します。このコマンドの no オプションを使用した場合、ゲートウェイは、RAS メッセージ用のトークンを生成しなくなります。
オールレベルのセキュリティ

この場合、ゲートウェイでは、登録およびコールで必要なすべての RAS メッセージに CAT を組み込むことができます。したがって、これは上記 2 レベルの組み合わせです。このオプションの場合、ARQ メッセージに含まれている CAT の検証は、コールを発信するユーザのアカウント番号および PIN に基づいて行われます。これ以外の RAS メッセージに含めて送信される CAT は、いずれも、ゲートウェイに設定されているパスワードに基づいて検証されます。したがって、コールごとのレベルと似ています。

ゲートキーパーの CLI から [no] security token required-for all と入力して、ゲートキーパーを設定します。このコマンドの no オプションを使用した場合、ゲートキーパーは、RAS メッセージ内のトークンをチェックしなくなります。

ゲートウェイ CLI から [no] security password <PASSWORD> level all と入力して、ゲートウェイを設定します。このコマンドの no オプションを使用した場合、ゲートウェイは、RAS メッセージ用のトークンを生成しなくなります。

IVR のないコールごとレベルの H.235 使用状況

IVR なしでは、コールごとのレベルで H.235 を使用できません。アカウントおよび PIN を収集するための IVR がない場合、ゲートウェイでは、クリアトークンを含まない（ただし、暗号トークンは含む）ARQ を送信する必要があります。 Cisco ゲートキーパーではクリアトークンだけを受け入れるため、コールは、セキュリティ拒否の理由を付けてゲートキーパーで拒否されます。

次の例は、アカウントおよび PIN を収集するための IVR が設定されていない、発信側ゲートウェイ（OGW）から収集された、h225 asn1 デバッグを示します。RRQ メッセージは、クリアトークンを含みますが、ARQ は含みません。ARJ メッセージがゲートウェイに返信されます。

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

主な問題

次のような主な問題を考慮する必要があります。

ゲートウェイおよびゲートキーパーの設定
ゲートキーパー上および RADIUS サーバ上の RADIUS 設定
ネットワークタイムプロトコル（NTP）：すべてのゲートウェイ上およびゲートキーパー上で、時刻が一致している必要があります。認証情報にはタイムスタンプが含まれているため、すべての Cisco H.323 ゲートウェイおよびゲートキーパー（または認証を実行する他のエンティティ）の同期が重要です。Cisco H.323 ゲートウェイは、NTP を使用して同期する必要があります。
バグによるソフトウェア障害

さまざまなレベルのデバッグおよびコールフロー

オールレベルのセキュリティは、登録レベルとコールごとの両方の場合をカバーするため、この例では、このラボをオールレベルのセキュリティでセットアップしてあります。登録部分および通常の VoIP コールのコールフローを、次の設定で説明します。

注：この設定は完了していません。デバッグ出力の間にさらにコマンドが続いています。設定、NTP、RADIUS など、すべての要素をチェックしなかった場合に発生するおそれのある問題を示すことを目的としています。さらに、ゲートウェイ ID とパスワードに設定されている値を確認できるように、ゲートウェイは、ゲートキーパー上でローカルに認証されます。この設定は、関連する設定のみを示すように省略されています。

!
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

この例では、次のデバッグをオンにしてあります。

まず、ゲートウェイが GRQ をゲートキーパーに送信し、ゲートキーパーは GCF をゲートウェイに送信します。次に、ゲートウェイは RRQ を送信し、RCF と RRJ のいずれかを待機します。

この設定で、ゲートウェイにはいずれのレベルのセキュリティも設定されていないため、ゲートウェイが伝送する GRQ には、トークンで必要な authenticationCapability が含まれていません。ただし、次の出力に示すように、ゲートキーパーでは、まだ GCF を返信します。

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

GRQ に含まれているメッセージの一部を次に示します。

authenticationCapability：このフィールドは、pwdHash の値だけを持ちます。これは、MD5 ハッシングを認証メカニズムとすることを示します。
algorithmOIDs：アルゴリズムのオブジェクト ID。この場合、伝送される値は、Message Digest 5 ハッシングのオブジェクト ID である、1 2 840 113549 2 5 です。

1 2 840 113549 2 5 は、iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) md5(5) に変換されます。したがって、MD5 パスワードハッシングを実行します。

RsadsiはRSA Data Security Inc.の略です。RSA Data Security, Inc.のOpen Systems Interconnection(OSI)オブジェクトIDは、米国規格協会(ANSI)によって登録された1.2.840.113549(0x2a、0x86、0x86、0xf7、0x0d)です。

ゲートキーパーは、直前のメッセージとして GCF を再度送信します。ゲートウェイは、次に、認証を受けるために使用するトークンについて記述する特定のフィールドを設定した RRQ を送信します。送信される asn1 RRQ メッセージを次の例に示します。

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

応答について説明する前に、前述の RRQ メッセージに含まれているいくつかの関連フィールドについて、ここで説明します。トークンには次の 2 種類があります。クリアトークン（いわゆる CAT）と暗号トークンです。

前述のように、Cisco ゲートキーパーでは、暗号トークンを無視します。ただし、ゲートウェイでは、通信先のゲートキーパーのタイプが不明であるため、引き続き両方を送信します。ゲートウェイで両方を送信するのは、暗号トークンを使用するベンダーがいるためです。

次に ClearToken 構文を示します。

tokenOID：トークンを識別するオブジェクト ID。
timeStamp：ゲートウェイの現在の協定世界時（UTC）時刻。00:00 1/1/1970 UTC からの秒数です。

元々ゲートキーパーから取得したかのように、暗黙の CHAP-Challenge として使用されます。
challenge：次のフィールドを使用してゲートウェイによって生成された 16 バイトの MD5 メッセージダイジェスト。

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

この計算は、RADIUS で実行されて（乱数、ゲートウェイパスワード、CHAP チャレンジがわかっているため）、必要なチャレンジが決定されます。CHAP Response = [ CHAP ID + UserPassword + CHAP Challenge ] MD5 Hash
random：この特定の要求を識別するために RADIUS によって使用される 1 バイトの値。

ゲートウェイでは、この RADIUS 要件を満たすために、認証要求ごとに可変モジュールの 256 を増やします。
generalID：セキュリティのレベルおよび RAS メッセージのタイプに基づく、ゲートウェイ H323-ID またはユーザアカウント番号。

注：これらのフィールドはすべて重要です。ただし、タイムスタンプと generalID の 2 つについて、特に注目します。この場合、タイムスタンプは 731030839、generalID は gwa-1@cisco.com です。

RRQ の cryptoToken には、トークンを生成するゲートウェイに関する情報が含まれています。これには、ゲートウェイ ID（ゲートウェイに設定されている H.323 ID）およびゲートウェイパスワードが含まれます。

このフィールドには、H.225で指定されたCryptoH323Tokenフィールドに定義されたcryptoToken型の1つが含まれています。現在、サポートされているcryptoTokenの唯一のタイプはcryptoEPPwdHashです。

cryptoEPPwdHash フィールドには、次のフィールドが含まれています。

alias：ゲートウェイエイリアス。これは、ゲートウェイの H.323 ID です。
timestamp：現在のタイムスタンプ。
token：Message Digest 5（MD5）エンコードされた PwdCertToken。このフィールドは、次の項目を含んでいます。
- timestamp：cryptoEPPwdHash と同じタイムスタンプ。
- password：ゲートウェイのパスワード。
- generalID：cryptoEPPwdHash に含まれるエイリアスと同じゲートウェイエイリアス。
- tokenID：オブジェクト ID。

この例のゲートキーパーからの応答を示します。

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

RRQ はゲートキーパーによって拒否されます。ゲートウェイの設定に NTP が設定されていないことがその理由です。ゲートキーパーでは、トークンのタイムスタンプを調べて、ゲートキーパーの時刻との関係で、許容可能な時間枠に入っているかどうかを確認します。現在、この時間枠は、ゲートキーパーの UTC 時刻の +/- 30 秒です。

ゲートキーパーでは、この時間枠を外れるトークンの場合、メッセージを廃棄します。これにより、スヌーピングされたトークンを再利用しようとするリプレイアタックを防ぎます。実際には、すべてのゲートウェイおよびゲートキーパーは、この時刻ずれの問題を回避するために、NTP を使用する必要があります。ゲートキーパーでは、トークン内のタイムスタンプが、ゲートキーパーの時刻の許容可能な時間枠内であることがわかります。したがって、ゲートキーパーでは、ゲートウェイを認証するために RADIUS をチェックしません。

次に、ゲートキーパーを NTP マスターとして指すように、ゲートウェイに NTP を設定します。この結果、ゲートウェイとゲートキーパーの両方で、時刻が同一になります。これが行われると、ゲートウェイは、新しい RRQ を送信します。今回、ゲートキーパーは、この新しい RRQ に RRJ で応答します。

次のデバッグは、ゲートキーパーから取得されています。デバッグは、ゲートキーパーが認証フェーズに進んでいるかどうかを確認するために実行します。

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

NTP を設定した後でも、ゲートキーパーは RRQ を拒否します。ただし、今回は、ゲートウェイの認証プロセスを経ます。ユーザ（ここでは、ゲートウェイ ID）が RADIUS 上の有効なユーザのリストに見つからないため、ゲートキーパーは RRQ を拒否します。ゲートウェイは、ゲートキーパーの設定内でローカルに認証されます。ユーザリストにはgwa-1と表示されますが、RRQのユーザはgwa-1@cisco.comであるため、これは正しいユーザではありません。

また、username gwa-1@cisco.com password 0 2222 コマンドをゲートキーパーに一度設定すれば、ゲートキーパーが RRQ を確認して、ゲートウェイを登録します。

このラボでは、別のゲートウェイ（gwa-2）が同じゲートキーパー（gka-1）に登録されています。ARQ、ACF、およびセットアップメッセージの様子を確認するために gwa-1@cisco.com から gwa-2 にコールが発信されます。

次のデバッグ収集は、発信側および着信側ゲートウェイ（gwa-2）から取得されています。

いくつかのデバッグメッセージについては、説明が含まれています。

発信側または着信側ゲートウェイからのデバッグをプリントする前に、次に示す、コールフローの説明を参照してください。

PSTN から SETUP メッセージを受信したゲートウェイは、ARQ をゲートキーパーに送信し、ACF をゲートキーパーから受信します。
ACF を受信したゲートウェイでは、ゲートウェイパスワード、H323-ID のエイリアス、現在の時刻を使用して CAT を生成します。トークンは、コール制御ブロック（CCB）に設定されます。
SETUP メッセージを着信側ゲートウェイに送信するとき、ゲートウェイでは、CCB からアクセストークンを取得し、SETUP メッセージ内の clearToken の nonStandardParameter フィールドに設定します。
着信側ゲートウェイでは、SETUP メッセージからトークンを除去し、nonStandardParameter から CAT に変換して ARQ に設定します。
ゲートキーパーでは、トークンのタイムスタンプを調べて、ゲートキーパーの時刻との関係で、許容可能な時間枠に入っているかどうかを確認します。現在、この時間枠は、ゲートキーパーの UTC 時刻の +/- 30 秒です。ゲートキーパーでは、この時間枠を外れるトークンの場合、メッセージを廃棄します。これにより、コールが拒否されます。
許容可能なトークンの場合、ゲートキーパーでは、RADIUS アクセス要求パケットをフォーマットし、CHAP チャレンジを確認するための適切な属性を入力して、RADIUS サーバに送信します。
サーバでは、ゲートウェイのエイリアスがサーバに既知であるという仮定に基づいて、このエイリアスに関連付けられているパスワードを検索し、エイリアス、パスワード、およびゲートキーパーからの CHAP チャレンジを使用して、サーバ自体の CHAP 応答を生成します。サーバの CHAP 応答がゲートキーパーから受信した応答と一致する場合、サーバは Access Accept パケットをゲートキーパーに送信します。一致しないか、ゲートウェイのエイリアスがサーバのデータベースにない場合、サーバでは、Access Reject パケットをゲートキーパーに返信します。
ゲートキーパーでは、Access Accept を受信した場合は ACF で、Access Reject を受信した場合は原因コード securityDenial の ARJ でゲートウェイに応答します。ゲートウェイが ACF を受信した場合、コールは接続されています。

次の例は、発信側ゲートウェイからのデバッグを示します。

注：セットアップのh225 asn1デバッグは、発信側ゲートウェイの例に続く着信側ゲートウェイの例と同じであるため、この例には含まれていません。

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

次の例は、着信側ゲートウェイ（TGW）からのデバッグを示します。 ACF を受け取ったため TGW が 2 番目のレッグをセットアップしており、コールが接続されていることに注意してください。

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)

ゲートウェイ IOS に関する問題

同じラボで、IOS イメージ 12.2(6a) を OGW にロードします。コールが発信されるとき、アカウントおよび PIN を収集するための IVR がゲートウェイに設定されていないにもかかわらず、OGW では、パスワードに基づくクリアトークンをまだ送信します。さらに、オールレベルを設定したゲートキーパーでは、このコールを受け入れます。この問題は、Cisco Bug ID CSCdw43224（登録ユーザ専用）に記述されています。

代替エンドポイントのセキュリティ

このドキュメントで前述したように、エンドツーエンドコールのセキュリティは、RAS/H.225 メッセージの clearTokens フィールドに入れて送信されるアクセストークンを使用して実現されます。そのようなセキュリティを可能にするために、送信元ゲートウェイでは、ゲートキーパーから ACF で受信したアクセストークンを、H.225 SETUP メッセージに入れて、宛先 H.323 エンドポイントに転送します。この宛先 H.323 エンドポイントでは、次に、SETUP メッセージで受信したアクセストークンを、アドミッション要求に入れてゲートキーパーに転送します。これを行うことにより、リモートゲートキーパーでは、アクセストークンの有効性に基づいてコールを許可できるようになります。アクセストークンの内容は、トークンを生成するエンティティによって異なります。セキュリティホールを最小限にし、中間者攻撃から防御するために、ゲートキーパーでは、アクセストークン内の宛先固有の情報をエンコードできます。つまり、alternateEndpoint が ACF に指定されている場合、ゲートキーパーでは、指定された alternateEndpoint ごとに別々のアクセストークンを準備できます。

Cisco ゲートウェイでは、接続を最初に確立しようとするとき、ACF の destCallSignalAddress フィールドのアドレスを使用して、clearToken フィールドで受信したアクセストークンを送信します。この試行が失敗し、続けて、代替エンドポイントとの接続を試行する場合、Cisco ゲートウェイでは、alternateEndpoints リストに関連アクセストークンがあれば、これを使用します。ACF で受信した alternateEndpoints リストにアクセストークンが含まれていない一方で、ACF にアクセストークンが含まれている場合、Cisco ゲートウェイでは、代替エンドポイントに接続しようとするすべての試行に、このアクセストークンを組み込みます。

OSP トークンのサポート

現在のところ、Open Settlement Protocol（OSP）およびこのプロトコルのトークンは、Cisco ゲートウェイのみでサポートされています。ゲートキーパーでのサポートはありません。ゲートウェイでは、決済サーバから受信した OSP トークンを認識し、着信側ゲートウェイへの Q.931 セットアップメッセージに挿入します。

各エンドポイントまたはゾーンの異なるセキュリティレベル

現時点では、エンドポイントまたはゾーンごとに異なるレベルのセキュリティを設定できません。セキュリティレベルは、そのゲートキーパーによって管理されているすべてのゾーンが対象になります。このような問題については、機能要求を提出できます。

ドメイン間のゲートキーパー間のセキュリティ

ドメイン間のゲートキーパー間のセキュリティでは、イントラドメインおよびドメイン間のゲートキーパー間要求をホップごとに検証できるようになります。つまり、宛先ゲートキーパーでは、CAT を廃棄したうえで、LRQ を前方へ転送する場合は新しく生成します。無効な LRQ シグニチャを検出した場合、ゲートキーパーでは、ロケーション拒否（LRJ）の送信によって応答します。

ゲートキーパー間のセキュリティの実装

発信側ゲートキーパーでは、LRQ の開始時または、ゾーン内コールの場合に ACF を送信しようとするときに、IZCT を生成します。このトークンは、ルーティングパスに沿って伝送されます。パス上の各ゲートキーパーでは、宛先ゲートキーパー ID と送信元ゲートキーパー ID を必要に応じて更新して、ゾーン情報を反映します。着信側ゲートキーパーでは、独自のパスワードを使用してトークンを生成します。このトークンは、ロケーション確認（LCF）メッセージに含めて返送され、OGW に渡されます。OGW では、このトークンを H.225 SETUP メッセージに組み込みます。TGW が受信したトークンは、ARQ answerCall に組み込んで転送され、RADIUS サーバを必要としないで、着信側ゲートキーパー（TGK）によって検証されます。

認証タイプは、ITU H.235で説明されているハッシュ付きパスワードに基づいています。具体的には、暗号化方式はパスワードのハッシュ付きMD5です。

IZCT の目的は、LRQ が外部ドメインから到着しているのかどうかおよびいずれのゾーン、いずれのキャリアから到着したのかを判別することです。TGK からのトークンを LCF に入れて OGW に渡すためにも使用されます。IZCT フォーマットには、次の情報が必要です。

srcCarrierID：ソースキャリア ID
dstCarrierID：宛先キャリア ID
intCarrierID：中間キャリア ID
srcZone：ソースゾーン
dstZone：宛先ゾーン
ゾーン間タイプ
- INTRA_DOMAIN_CISCO
- INTER_DOMAIN_CISCO
- INTRA_DOMAIN_TERM_NOT_CISCO
- INTER_DOMAIN_ORIG_NOT_CISCO

この機能は、ゲートウェイと Carrier Sensitive Routing（CSR）サーバのいずれからのキャリア ID も必要としないで、正常に機能します。その場合、キャリア ID に関するフィールドは空になります。ここに示す例は、キャリア ID を含んでいません。コールフロー、リリースとプラットフォームのサポート、および設定の詳細については、「ドメイン間ゲートキーパーセキュリティ拡張機能」を参照してください。

ゲートキーパーの設定

IZCT 機能を使用するには、ゲートキーパー上に次の設定を必要とします。

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

パスワードは、6 ～ 8 文字である必要があります。次のように、外部ドメインに含まれているゾーンを識別します。

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]

IZCT コールフロー

次の図は、IZCT フローを示しています。

この設定に含まれている、ゲートウェイおよびゲートキーパーの名前は、IZCT コールフロー図で使用されている名前と同じですが、小文字です。コールフローについては、設定の後に、デバッグの説明を含めて説明します。

IZCT 機能およびコールフローを説明するために、最初の例には、イントラドメインのゲートウェイからゲートキーパーへのセキュリティがありません。その後に、TGW で IZCT を生成できず、その結果 TGK1 がコールを拒否する例を示します。これは、この機能の設計通りの動作を確認することを目的としています。このすべてのセットアップは、IZCT コールフロー図に示すトポロジに基づいています。

例 1：ゲートキーパー間のセキュリティのみのコールフロー

次の例は、すべてのゲートウェイおよびゲートキーパーについて、関連する設定を示します。

OGW 設定	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

OGW 設定

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

OGK1 設定	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

OGK1 設定

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

OGK2 設定	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

OGK2 設定

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

デバッグによるコールフロー

これらの例では、デバッグを使用して、コールフローを説明してあります。

キャリア E 上のユーザが、キャリア 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)

発信側ゲートウェイのダイヤルピア（タグ = 3653）は、RAS 用に設定されているため、ARQ を 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

OGK1はARQを受信すると、宛先がリモートゾーンOGK2によってサービスを受けていると判断します。次に、IZCTが必要であることを識別します（CLIを使用）。security izct password <pwd> を利用）。OGK1 は、LRQ を送信する前に、IZCT の作成に進みます。次に、IZCT および LRQ を OGK2 に送信し、RIP メッセージを 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

LRQ を受信した OGK2 は、IZCT をチェックします。設定から、LRQ に IZCT も組み込む必要があることがわかります。次に、OGK2はizctSrcZoneとizctDstZoneをogk2に変更して新しいIZCTを作成し、LRQをTGK2に転送します。LRQをTGK2に送信した後、RIPメッセージをOGK1に送送返します。

ゲートキーパーがクラスタの一部である場合は、クラスタ名が SrcZone または 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 は、LRQ を外部ドメインから受信したことを判別します。TGK2 は、IZCT の dstZone を自身の ID で、interZoneType を INTER_DOMAIN_CISCO で更新します。次に、新しい CAT を作成し、更新した IZCT および LRQ を TGK1 に渡します。

TGK2 では、この 2 つのシナリオのいずれでも、受信した LRQ のゾーンを外部ドメインゾーンとして扱います。

TGK2 のリモートゾーンリストには、LRQ の受信元のゾーンが含まれていません。
TGK2 のリモートゾーンリストには、LRQ の受信元のゾーンが含まれています。ゾーンは、外部ドメインフラグでマークされています。

次に、Request In Progress メッセージを 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

通常、TGK1 では、IZCT の dstCarrierID を Carrier E に更新します。この内容は、ルーティングプロセスによって決定されます。ただし、キャリアは使用されないため、確認することはできません。TGK1 は、IZCT のパスワードを使用して、ハッシュトークンを生成します。このizctHashは、TGWからTGK1が受信するanswerCall ARQを認証するために使用されます。これは、後でOGWからVoIP設定メッセージを受信したときにTGWから受信されます。

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 は、LCF から IZCT を抽出し、ACF に組み込んで 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

OGW は、H.225 SETUP メッセージに組み込んで、IZCT を TGW に送信します。

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

TGW は、ARQ answerCall に組み込んで、IZCT を TGK1 に渡します。

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 は、宛先 IZCT を正常に認証します。これは、TGK1 で、IZCT 内にハッシュを生成し、ACF を 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
   }
  }

TGW では、ACF の受信後に、Carrier D へのコールを確立します。

例 2：受信したセットアップメッセージから TGW で IZCT を抽出できないため、コールが失敗します。

この例は、例1と同じトポロジと設定に基づいています。この例では、TGWのソフトウェアが、IZCTがサポートされていないバージョンに変更されています。この場合、TGW では、セットアップメッセージから IZCT を抽出できません。この結果、TGK1 では、セキュリティ拒否理由を接続解除としてコールを拒否することになります。

コールフローは例 1 と同一であるため、この例では、セットアップメッセージ、ARQ、および TGW 上の ARJ のみを示します。

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

ゲートウェイからゲートキーパー（H.235）およびゲートキーパーからゲートキーパー（IZCT）へのセキュリティのトラブルシューティングガイド

偏向のない言語

翻訳について

目次

概要

イントラドメインのゲートウェイからゲートキーパーへのセキュリティ

トークンで渡されたタイムスタンプ

シスコによる H.235 勧告の実装方法

セキュリティレベルの設定方法

IVR のないコールごとレベルの H.235 使用状況

主な問題

さまざまなレベルのデバッグおよびコールフロー

ゲートウェイ IOS に関する問題

代替エンドポイントのセキュリティ

OSP トークンのサポート

各エンドポイントまたはゾーンの異なるセキュリティレベル

ドメイン間のゲートキーパー間のセキュリティ

ゲートキーパー間のセキュリティの実装

ゲートキーパーの設定

IZCT コールフロー

デバッグによるコールフロー

関連情報

提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

ゲートウェイからゲートキーパー（H.235）およびゲートキーパーからゲートキーパー（IZCT）へのセキュリティのトラブルシューティング ガイド

偏向のない言語

翻訳について

目次

提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

ゲートウェイからゲートキーパー（H.235）およびゲートキーパーからゲートキーパー（IZCT）へのセキュリティのトラブルシューティングガイド