CUCM SDI トレースでの H.323 コールの追跡

CscTsWebDocs · ‎2012-08-06

免責事項：本文書は CUCM 7.X を想定していますが、若干の調整を行えば、すべての CUCM バージョンに適用可能です。

トレースの有効化

トレースを有効にするには、この文書に従います。H.225 および H.245 のチェックボックスに特に注意してください。

問題の再現/テストコールの実施

発信者の番号、受信者の番号、コール時刻の情報を取得します。

高度な分析アプリケーションのダウンロード

個人的には Notepad++ を好んで使用していますが、ハイライト機能や検索機能を備えたテキストエディタであればどれでも使用できます。トレースファイルで unix2dos を事前に実行する場合、Windows 標準のメモ帳を使用することもできます。TranslatorX も便利です。

トレースの分析

楽しみは全部ここにあります。たくさんのトレースファイルが複数のフォルダに格納されています。この例で使用したトレースは、添付の H323Trace.zip ファイルでダウンロードできます。収集したギガバイトにも及ぶファイルのどこかに、目的のコールがあるはずです。目的のファイルを見つけて、追跡する方法を説明します。

問題のコールの特定

どのトレースファイルを探せばよいかを知るために、テキストエディタの Grep 機能、または Linux grep などのツールを使用します。

ここで例にするコールの詳細は次のとおりです。

発信者 - 7021004

受信者 - 8011000

コール時刻（電話メニューの発信履歴から取得）- 11:45

検索クエリは次のようになります。

cn="7021004
dd="8011000

この 2 つの文字列によって、CUCM の番号分析の行が検索されます。cn は発信番号を表します。dd はダイヤルした番号を表します。grep を使用したトレースファイル検索を見てみましょう。

jasburns@jasburns-gentoo ~/trace/H323Trace $ grep -REi --include "ccm*.txt" "dd=\"8011000" *
cucm7-sub1/2010-06-24_11-47-16/cm/trace/ccm/sdi/ccm00000002.txt:06/24/2010 11:45:32.095
CCM|Digit analysis: match(pi="2", fqcn="7021004", cn="7021004",plv="5", pss="",
TodFilteredPss="", dd="8011000",dac="0")

grep コマンドで使用するフラグ

-R 繰り返し

-E 拡張正規表現（regex を使用したい場合）

-i 大文字小文字を区別しない検索（大まかに指定したい場合）

--include ccm*.txt のように指定して、該当する名前のファイルのみを検索に含める

発信番号のみわかっている場合は、それに応じて検索文字列を変更します。結果に何も表示されない場合、cn または dd の部分を削除して番号のみを検索します。7 桁の番号の検索がうまくいかない場合、下 4 桁のみを検索してコールを見つけることができます。

検索結果から、次の場所にファイルがあることがわかります。

cucm7-sub1/2010-06-24_11-47-16/cm/trace/ccm/sdi/ccm00000002.txt

また、この番号分析の行から興味深いことがわかります。

pss="" および TodFilteredPss="" は、発信電話のコーリングサーチスペースが <None> に設定されていることを意味します。この値は通常、発信者の CSS 内のパーティションの順序付けされたリストです。

テキストエディタでトレースファイル ccm*02.txt を開き、この行を見てみましょう。

発信者の特定

数行上に戻って辿ると、コールを発信した SCCP 電話機がわかります。

06/24/2010 11:45:32.089 CCM|StationInit: (0000003) SoftKeyEvent softKeyEvent=1(Redial)

その特定の IP 電話の TCP ハンドルは 0000003 です。これは、この電話機が、このノードでの CCM 処理を開始してから 3 つ目に登録されたものであることを示します。この特定の TCP ハンドルについて grep を実施し、その電話機との間で送受信されたすべての SCCP メッセージを取得することができます。

StationInit - 電話機がこのメッセージを CUCM に送信

StationD - CUCM がこのメッセージを電話機に送信

Notepad++ を使用してトレースでこれをハイライトします。ハンドルをハイライトして、右クリックし、[Using 1st Style] を選択します。トレースファイル内のすべてのハンドルが水色で表示されます。

コールのプロセス ID と受信者のプロセス ID の特定

各コールレッグには、CallID（固有識別子）があります。これはそのコールのレッグの固有識別子です。一般に CI と呼ばれます。

各コールには、cdcc プロセスもあります。これはそのコールのプライマリ呼制御プロセスです。

各受信者に、関連付けられたプロセスがあります。これは CUCM がコールを送信する場所です。

これらのすべてを番号分析ブロックの後の数行で知ることができます。

06/24/2010 11:45:32.095 CCM|Digit analysis: insert daResEntry to daResCache.
KeyCi=42514739 ,PID:Cdcc(2,174,4)

ここでコールの CI が 42514739 であること、および cdcc（2,174,4）がわかります。これらもトレースでハイライトしておくと役立ちます。

dmpidreq および dmpidres（要求および応答）を通してコールを拡張する先のプロセス ID（pid）を取得できます。

06/24/2010 11:45:32.096 CCM|Digit analysis: wait_DmPidRes- Partition=[] Pattern=[801XXXX]
Where=[], cmDeviceType=[AccessDevice], OutsideDialtone =[1], DeviceOverride=[0],
PID=RouteListControl(1,100,61,2)

一致したルートパターンは 801XXXX で、このパターンは RouteListControl にポイントしています。このプロセス ID は（1,100,61,2）です。

着信プロセスが正しいノードに到達するまでの追跡

ルートリストコントロールプロセスはノード 1（パブリッシャ）に存在し、私たちは現在サブスクライバ上にいます。サブスクライバは CUCM プロセス内に存在します（100）。つまり、サブスクライバは、パブリッシャ上のルートリストコントロールにメッセージを送信する必要があります。

通常、SDL トレースファイルを見て、ノード ID をサーバ名と対応付けます。たとえば、cucm7-sub1 はノード 2（SDL002_*.txt）であることがわかります。

信号はノード 1 に送信され、ノード 2 はサブスクライバであることがわかったため、ノード 1 の SDL トレースフォルダを検索することができます。ノード 1 は常にパブリッシャサーバです（ただし、CCM のバージョンおよびサービスを有効または無効にしているかによって、パブリッシャが常にノード 1 にならない場合があります）。

対象時刻 11:45:32.096 のパブリッシャの CCM トレースを開きます。

cucm7-pub\2010-06-24_11-47-15\cm\trace\ccm\sdi\ccm00000002.txt

06/24/2010 11:45:32.100 CCM|RouteListControl::idle_CcSetupReq - RouteList(ICT_RL)

これは、サブスクライバからパブリッシャへのインバウンドリクエストを示しています。「ICT_RL」という名前のルートリストにコールが送られていることがわかります。

このルートリストでは各ルートグループの解析が行われており、次のトレースを見ると、ルートグループのメンバーが選択されているのがわかります。

06/24/2010 11:45:32.101 CCM|SMDMSharedData::findLocalDevice - Name=ICTto801
Key=005cee5b-ef72-4919-4855-5983ba8b23f2 isActvie=1 Pid=(1,153,7) found

幸運なことに、そのルートグループ内の対象のデバイスの PID もノード 1 にあります。トレース内を少し下にスクロールすると、この InterClusterTrunk 上でのアウトバウンド H.323 コールが確認できます。

アウトバウンド H.225 設定の検出

ここでは、この H.225 アウトバウンドセッション向けに作成されたプロセスを見ていきます。CUCM はアウトバウンドの TCP 接続を試みています。

06/24/2010 11:45:32.188 CCM|H225D::restart0_TcpConnectionInfo: H225Cdpc(1,100,154,3)

次に実際の H.323 アウトバウンド設定を見てみます。

06/24/2010 11:45:32.193 CCM|SPROCRas - {
  h323-uu-pdu 
  {
    h323-message-body setup : 
      {
        protocolIdentifier { 0 0 8 2250 0 5 },
        sourceAddress 
        {
          dialedDigits : "7021004",
          h323-ID : {"7021004", {0, 0, 0, 0}, ...}
        },
        sourceInfo 
        {
          vendor 
          {
            vendor 
            {
              t35CountryCode 181,
              t35Extension 0,
              manufacturerCode 18
            },
            productId '436973636F43616C6C4D616E61676572'H,
            versionId '31'H
          },
          terminal 
          {
          },
          mc FALSE,
          undefinedNode FALSE
        },
        destinationAddress 
        {
          dialedDigits : "8011000"
        },
        activeMC FALSE,
        conferenceID '807B41849C7D31C2030003010E302CCF'H,
        conferenceGoal create : NULL,
        callType pointToPoint : NULL,
        sourceCallSignalAddress ipAddress : 
          {
            ip '0E302C15'H,
            port 1720
          },
        |<CLID::StandAloneCluster><NID::CUCM7-PUB><LVL::State Transition><MASK::0100>
06/24/2010 11:45:32.193 CCM|callIdentifier 
        {
          guid '807B41849C7D31C2030003010E302CCF'H

このメッセージのうち、コールの残りの追跡に最も重要な部分は、guid '807B41849C7D31C2030003010E302CCF'H です。これはコール固有の識別子です。grep または wingrep を使用してこの guid を検索できます。この guid が出現するトレースがいくつあるかを調べ、これらすべてのトレースを任意のエディタで開くことができます。

開かれた H.225 メッセージ本文に加え、H.225 メッセージのコンパクトな出力もあります。

11:45:32.193 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
11:45:32.193 CCM|Ie - H225BearerCapabilityIe IEData= 04 03 80 90 A2 
11:45:32.193 CCM|Ie - H225CallingPartyIe IEData= 6C 09 00 81 37 30 32 31 30 30 34
11:45:32.193 CCM|Ie - Q931CalledPartyIe IEData= 70 08 80 38 30 31 31 30 30 30 
11:45:32.194 CCM|IsdnMsgData2= 08 02 00 03 05 04 03 80 90 A2 6C 09 00 81 37 30 32

11:45:32.212 CCM|In  Message -- H225CallProceedingMsg -- Protocol= H225Protocol
11:45:32.212 CCM|IsdnMsgData1= 08 02 80 03 02 7E 00 55 05 21 80 06 00 08 91 4A 00

これを使うと、コールのすべてのメッセージを簡単に追跡できます。最初のメッセージは Outbound Setup で、着信番号と発信番号の ASCII 値が含まれていることがわかります。

発信 37 30 32 31 30 30 34

着信 38 30 31 31 30 30 30

これらは ASCII の数値なので、2 桁の各番号の頭の 3 を除外するだけで、番号を取得できます。これは、遠隔の H.323 デバイスに送信される番号をダブルチェックする際に非常に便利です。

2 番目のメッセージは Inbound Proceeding メッセージです。

ISDN 識別子に基づいてこれらのメッセージを結び付けます。これは、第 3 オクテットから開始されます。

識別子の部分は 0 03 です。最初の文字は方向を示します。この例での 0 はアウトバウンド方向を示します（Outbound SETUP が 00 03）。インバウンド方向はアウトバウンド + 8（hex）、またはこの例での 8 です（Inbound CallProceeding が 80 03）。

ネゴシエーションされた H.245 ポートの検出

Setup、Proceeding、Alerting、Connect、Release Complete などのメッセージは H.225 プロトコル上でやり取りされます。これらのメッセージは通話制御用です。そのコールのメディアストリームに使用される IP アドレス、UDP ポート番号、コーデックのネゴシエーションに使用される、完全に別の H.245 と呼ばれるプロトコルがあります。

Alerting または Connect メッセージのどちらも、着信側のエンドポイントは H.245 アドレスと呼ばれるセクションに配置されます。このポートがトリガーとなって、発信者は、H.245 メッセージの交換を目的とした新しいセッションを受信者との間に確立します。

たとえば Notepad++ を使用してすべてのトレースファイル中で guid を検索し、そのポートのメッセージが見つかるまですべての H.225 メッセージを参照します。

ここで、H.245 ポートが 58820 であり、Connect メッセージで 11:45:34（受信者が応答したとき）に受信されたことがわかります。このポートは次の手順で重要であるため、ハイライトしておきます。

H.245 ポートに基づく H.245 TTPid の特定

H.245 ポートがわかったら、次にプロセス識別子を探し、このコールに関するすべての H.245 メッセージを見つけることができます。

注

この手順は「Slow Start」コールにのみ適用されます。「Fast Start」については別の機会に説明します。

H.245 ポートがインバウンド H.225 メッセージで受信される場合、トレースでポート番号を検索します。H.245 プロセスを作成するための後処理が必要です。

H.245 ポートがアウトバウンド H.225 メッセージで送信される場合、トレースでポート番号を検索します。H.245 プロセスを行うための処理は終わっているので、次にポート番号と共にメッセージを送信します。

これは、この例では、インバウンド H.225 メッセージです。H.245 ポート番号を検索し、次のような行を見つけます。

06/24/2010 11:45:34.167 CCM|H245Interface(3)::start_Transition, (H245Client session)
ip = (14.48.44.80), port = 58820, TA provided by Callee

この例では、作成された H.245 インターフェイスのプロセス ID が 3 H245Interface(3) であることがわかります。このコールのすべての H.245 メッセージがそのプロセスで交換されます。完全なプロセス ID を取得するには、検索して次のようなメッセージを見つけます。

06/24/2010 11:45:34.181 CCM|H245ASN - TtPid=(1,100,16,3) -Outgoing -value
MultimediaSystemControlMessage ::= request : terminalCapabilitySet

これは Outbound TCS です。以降の検索文字列として使用する識別子は TtPid=(1,100,16,3) です。これを別の好きな色でハイライトしてください。

Notepad++ の「Find in all Open Documents」（またはご利用のテキストエディタの類似の検索）を使用して、コールの開始から終わりまでの完全な H.245 セッション出力を取得します。

Terminal Capability Set での機能の検出

各サイドが TCS（Terminal Capability Set; ターミナル機能セット）メッセージで対応機能をアドバタイズします。まず一方がすべての対応機能をアドバタイズします。応答側が一致する対応機能を応答します。

ここではアウトバウンド TCS が次の機能に対応していることをアドバタイズしています。

        {
          capabilityTableEntryNumber 3,
          capability receiveAudioCapability : g711Ulaw64k : 40
        },
        {
          capabilityTableEntryNumber 4,
          capability receiveAudioCapability : g711Alaw64k : 40
        },
        {
          capabilityTableEntryNumber 5,
          capability receiveAudioCapability : g729wAnnexB : 6
        },
        {
          capabilityTableEntryNumber 6,
          capability receiveAudioCapability : g729AnnexAwAnnexB : 6
        },
        {
          capabilityTableEntryNumber 7,
          capability receiveAudioCapability : g729 : 6
        },
        {
          capabilityTableEntryNumber 8,
          capability receiveAudioCapability : g729AnnexA : 6
        },
        {
          capabilityTableEntryNumber 9,
          capability receiveAndTransmitUserInputCapability : dtmf : NULL

G.711U/A、最大 40 ミリ秒でのパケット化（フレーム毎に 4 つのデータサンプル、各サンプル 10 ミリ秒）

G.729/A/B、フレーム毎に 6 つのデータサンプル（各サンプルが 10 ミリ秒のため、60 ミリ秒でのパケット化）

注

G.711 は TCS の RTP パケット間にミリ秒のパケット化間隔を使用

G.729 は TCS 内の各 RTP パケットにつき 10 ミリ秒のデータサンプルの数を使用

各サンプルが 10 ミリ秒の長さであると理解していれば、両者間の変換は簡単です。

最も一般的なパケット化は 20 ミリ秒、または 1 RTP パケットにつき 2 つの音声サンプルです。

インバウンドの機能を見ると、すべて同じ機能がサポートされていることがわかります。

使用されたコーデック、IP アドレス、UDP ポートの特定

発信電話が登録されているサブスクライバトレースに戻って見ると、リージョン設定が G.711 向けに設定されていることがわかります（64kbps とトレースに記載）。

06/24/2010 11:45:34.194 CCM|RegionsServer::MatchCapabilities -- kbps=64,
capACount=6, capBCount=8

パブリッシャでは遠端の H.323 ノードに 20 ミリ秒の G.711 が使用されていることがわかります。

06/24/2010 11:45:34.246 CCM|H245ASN - TtPid=(1,100,16,3) -Outgoing -value
MultimediaSystemControlMessage ::= request : openLogicalChannel : 
    {
      forwardLogicalChannelNumber 1,
      forwardLogicalChannelParameters 
      {
        dataType audioData : g711Ulaw64k : 20,

また、20 ミリ秒の G.711 インバウンドメッセージを取得します。

サブスクライバで TCP ハンドルに戻ると、発信側の SCCP 電話機が G.711 音声チャネルを Open にするように指示されたことがわかります。電話機の応答（StationInit）は UDP ポート 24418 をリッスンするようになっています。

06/24/2010 11:45:34.255 CCM|StationInit: (0000003) OpenReceiveChannelAck Status=0,
IpAddr=IpAddr.type:0 ipAddr:0x0e302ccf000000000000000000000000(14.48.44.207),
Port=24418, PartyID=33554435

H.245 セッションが継続中のノードに戻ると、次の送信 OpenLogicalChannelAck が確認できます。H.323 レッグで送信する UDP RTP ポート番号は、電話機が SCCP ORCAck で応答した同じポート、24418 であることに注目してください。

06/24/2010 11:45:34.257 CCM|H245ASN - TtPid=(1,100,16,3) -Outgoing -value
MultimediaSystemControlMessage ::= response : openLogicalChannelAck : 
    {
      forwardLogicalChannelNumber 1,
      forwardMultiplexAckParameters h2250LogicalChannelAckParameters : 
        {
          sessionID 1,
          mediaChannel unicastAddress : iPAddress : 
              {
                network '0E302CCF'H,
                tsapIdentifier 24418
              },

受信 OpenLogicalChannelAck は受信者が 23362 をリスニングしていることを示しています。

06/24/2010 11:45:34.259 CCM|H245ASN - TtPid=(1,100,16,3) -Incoming -value
MultimediaSystemControlMessage ::= response : openLogicalChannelAck : 
    {
      forwardLogicalChannelNumber 1,
      forwardMultiplexAckParameters h2250LogicalChannelAckParameters : 
        {
          sessionID 1,
          mediaChannel unicastAddress : iPAddress : 
              {
                network '0E302CCC'H,
                tsapIdentifier 23362
              },

発信側の SCCP 電話機が登録されているパブリッシャサーバに戻ると、CUCM が、確立済みのコーデックを使用して RTP をこの新しい IP とポートに送信するように指示していることがわかります。

06/24/2010 11:45:34.260 CCM|StationD:    (0000003) startMediaTransmission
conferenceID=42514739 passThruPartyID=33554435 remoteIpAddress=IpAddr.type:0
ipAddr:0x0e302ccc000000000000000000000000(14.48.44.204) remotePortNumber=23362
milliSecondPacketSize=20 compressType=4(Media_Payload_G711Ulaw64k)

これより後のコールでは、受信者が保留、再開、切断を押します。先に説明した技法のすべてを使用して、これらの手順の振る舞いを詳細に追跡することができます。

-------------------------------------

翻訳元

https://supportforums.cisco.com/docs/DOC-11779