Cisco Unified Communications Manager トラブルシューティング ガイド リリース 9.0(1)

偏向のない言語

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

翻訳について

このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。

マニュアルのコンテンツ
このマニュアル内で検索
ご利用いただける言語
Download Options

Book Title

Cisco Unified Communications Manager トラブルシューティング ガイド リリース 9.0(1)

Chapter Title

ケース スタディ：Cisco Unified IP Phone と Cisco IOS ゲートウェイ間のコールのトラブルシューティング

検索結果

Updated:
2017年6月29日

章のタイトル： ケース スタディ：Cisco Unified IP Phone と Cisco IOS ゲートウェイ間のコールのトラブルシューティング

目次

このケース スタディでは、ローカル PBX を経由して接続している電話機、または公衆電話交換網（PSTN）上の電話機に、Cisco IOS ゲートウェイを経由してコールを発信する Cisco Unified IP Phone について説明します。 概念的には、コールが Cisco IOS ゲートウェイに到達すると、ゲートウェイはそのコールを FXS ポートまたは PBX に接続された電話機のいずれかに転送します。 PBX に転送されたコールは、ローカル PBX に接続された電話機で終端するか、または PBX によって PSTN 経由で転送され、PSTN 上で終端します。

関連情報
コール フローのトレース
ケース スタディ：Cisco Unified IP Phone コールのトラブルシューティング
Cisco IOS ゲートキーパーのデバッグ メッセージと表示コマンド...
Cisco IOS ゲートウェイのデバッグ メッセージと表示コマンド...
T1/CAS インターフェイスを使用する Cisco IOS ゲートウェイ
T1/PRI インターフェイスを使用する Cisco IOS ゲートウェイ

コール フローのトレース

ここでは、Cisco Communications Manager トレース ファイル CCM000000000 の例を使用してコール フローについて説明します。 このケース スタディのトレースでは、コール フロー自体に焦点を絞っています。 詳細なトレース情報については、Cisco Unified IP Phone コールに関連するトピックを参照してください（たとえば、初期化、登録、およびキープアライブ メカニズムなど）。

このコール フローでは、Cluster 2 にある Cisco Unified IP Phone（電話番号 1001）が PSTN 上の電話機（電話番号 3333）にコールを発信します。 トレースでデバイスを追跡するには、デバイスの TCP ハンドル値、タイムスタンプ、または名前を調べます。 デバイスの TCP ハンドル値は、デバイスがリブートされるかオフラインになるまで変わりません。

次のトレースでは、Cisco Unified IP Phone（1001）がオフフックになっています。 トレースは、Cisco Unified IP Phone に表示される固有のメッセージ、TCP ハンドル、発信番号を示しています。 ユーザはまだ番号をダイヤルしていないため、この時点では着信番号は表示されていません。

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001

次のトレースでは、ユーザが DN 3333 をダイヤルしています（数字を 1 つずつダイヤルします）。 番号 3333 は、PSTN ネットワーク上の電話機の宛先番号です。 Cisco Unified Communications Manager の番号分析プロセスが現在アクティブになっており、コールのルーティング先を検出するために番号を分析しています。 番号分析の詳細については、Cisco Unified IP Phone コールに関連するトピックを参照してください。

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

次のトレースでは、番号分析が完了して発信側と着信側が一致し、情報が解析されています。

|CallingPartyNumber=1001|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

次のトレースでは、番号 0 が発信元のロケーションを示し、番号 1 が宛先のロケーションを示しています。 BW = -1 は、発信元のロケーションの帯域幅を示します。 値 -1 は、帯域幅が無限であることを暗黙的に示します。 コールは LAN 環境にある Cisco Unified IP Phone から発信されたため、帯域幅は無限であると見なされます。 BW = 64 は、宛先のロケーションの帯域幅を示します。 コールの宛先は PSTN 上にある電話機で、使用されるコーデック タイプは G.711（64 Kbps）です。

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

次のトレースは、発信側および着信側の情報を示しています。 この例では、管理者が表示名（John Smith など）を設定していないため、発呼側の名前と番号は同じです。

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98

次のトレースは、H.323 コードが初期化され、H.225 セットアップ メッセージを送信していることを示しています。 従来の HDLC SAPI メッセージ、16 進表記の着信側の IP アドレス、およびポート番号も確認できます。

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol15:20:21.421 CCM|MMan_Id= 1. (iep=  0 dsl=  0 sapi=  0 ces=  0 IpAddr=e24610ac IpPort=47110)

次のトレースは、発信側および着信側の情報と H.225 アラート メッセージを示しています。 また、Cisco Unified IP Phone の 16 進数値と IP アドレスのマッピングも示されています。 Cisco Unified IP Phone（1001）の IP アドレスは 172.16.70.231 です。

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d9815:20:21.453 CCM|In  Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)

次のトレースは、このコールで使用されている圧縮タイプ（G.711 mu-law）を示しています。

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k

H.323 は H.225 アラート メッセージが送信されたあとで、H.245 を初期化します。 次のトレースは、発信側および着信側の情報と H.245 メッセージを示しています。 TCP ハンドル値はこれまでと同じで、同じコールが続いていることを示しています。

ONE FOR EACH Channel- 16:53:36.855 CCM|H245Interface(3) paths established ip = e98e6b80, port = 1304|<CT::1,100,105,1.1682><IP::128.107.142.233>ONE FOR EACH Channel- 16:53:37.199 CCM|H245Interface(3) OLC outgoing confirm ip = b870701, port = 49252|<CT::1,100,128,3.9><IP::1.7.135.11>
 
H323 EP has answered the call and H245 channel setup in progress:
16:53:13.479 CCM|In  Message -- H225ConnectMsg -- Protocol= H225Protocol|
 
16:03:25.359 CCM|StationD(1):  TCPPid = [1.100.117.1] CallInfo callingPartyName='' callingParty=13001 cgpnVoiceMailbox=    calledPartyName='' calledParty=11002 cdpnVoiceMailbox=    originalCalledPartyName='' originalCalledParty=11002 originalCdpnVoiceMailbox= originalCdpnRedirectReason=0    lastRedirectingPartyName='' lastRedirectingParty=11002 lastRedirectingVoiceMailbox= lastRedirectingReason=0    callType=2(OutBound) lineInstance=1 callReference=16777217. version: 0|<CT::1,100,11,2.1><IP::><DEV::>
 
16:03:25.328 CCM|StationD(1):   TCPPid = [1.100.117.1] OpenReceiveChannel conferenceID=16777217 passThruPartyID=16777233 millisecondPacketSize=20    compressionType=4(Media_Payload_G711Ulaw64k) qualifierIn=?. myIP: e98e6b80 (128.107.142.233)|<CT::1,100,11,1.1><IP::><DEV::>
16:03:25.359 CCM|StationD(2):   TCPPid = [1.100.117.2] StartMediaTransmission conferenceID=16777218 passThruPartyID=16777249 remoteIpAddress=e98e6b80(64.255.0.0)    remotePortNumber=65344 milliSecondPacketSize=20 compressType=4(Media_Payload_G711Ulaw64k) qualifierOut=?. myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.213><IP::128.107.142.233>
16:03:25.375 CCM|StationD(2):   TCPPid = [1.100.117.2] star_StationOutputStartMultiMediaTransmission conferenceID=16777218 passThruPartyID=16777250 remoteIpAddress=e98e6b80(66.255.0.0)    remotePortNumber=65346 compressType=101(Media_Payload_H263) qualifierOut=?. myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.215><IP::128.107.142.233>
16:03:25.328 CCM|StationD(1):   TCPPid=[1.100.117.1] OpenMultiReceiveChannel conferenceID=16777217 passThruPartyID=1000011 compressionType=101(Media_Payload_H263) qualifierIn=?.   myIP: e98e6b80 (128.107.142.233)|<CT::1,100,11,1.1><IP::><DEV::>

次のトレースは、H.225 接続メッセージとその他の情報を示しています。 H.225 接続メッセージが受信されると、コールが接続します。

15:20:22.968 CCM|In  Message -- H225ConnectMsg -- Protocol= H225Protocol15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 16758 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)
16:03:25.359 CCM|MediaManager(1) - wait_AuConnectInfo - recieved response, fowarding, CI(16777217,16777218)|<CT::1,100,105,1.213><IP::128.107.142.233>
16:03:25.359 CCM|MediaCoordinator - wait_AuConnectInfoInd|<CT::1,100,105,1.213><IP::128.107.142.233>
16:03:25.359 CCM|ConnectionManager - wait_AuConnectInfoInd, CI(16777217,16777218)|<CT::1,100,105,1.213><IP::128.107.142.233>

次のメッセージは、Cisco Unified IP Phone（1001）からのオンフック メッセージを受信していることを示しています。 オンフック メッセージを受信するとすぐに、H.225 と Skinny Station デバイスの接続解除メッセージが送信され、H.225 メッセージの全文が表示されます。 この最後のメッセージには、コールが終端したことが示されています。

15:20:27.296 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x5138d9815:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to (64,5) and remove connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:28.328 CCM|In  Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:03:33.344 CCM|StationInit - InboundStim - StationOnHookMessageID: Msg Size(received, defined) = 4, 12|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|ConnectionManager - wait_AuDisconnectRequest(16777217,16777218): STOP SESSION|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] CloseReceiveChannel conferenceID=16777218 passThruPartyID=16777249.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] StopMediaTransmission conferenceID=16777218 passThruPartyID=16777249.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] star_StationOutputCloseMultiMediaReceiveChannel conferenceID=16777218 passThruPartyID=16777249.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] star_StationOutputStopMultiMediaTransmission conferenceID=16777218 passThruPartyID=16777250.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
関連情報
ケース スタディ：Cisco Unified IP Phone コールのトラブルシューティング

Cisco IOS ゲートキーパーのデバッグ メッセージと表示コマンド

このケース スタディのトポロジでは、Cisco IOS ゲートキーパーで debug ras コマンドがオンになっています。 SDI トレースの詳細については、コール フロー トレースに関するトピックを参照してください。

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco Unified Communications Manager（172.16.70.228）に対するアドミッション要求（ARQ）を受信し、その他の正常なリモート アクセス サーバ（RAS）メッセージが後続していることを示しています。 最後に、Cisco IOS ゲートキーパーがアドミッション確認（ACF）メッセージを Cisco Unified Communications Manager に送信しています。

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] on sock [0x60AF038C]*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

次のデバッグ メッセージは、コールが進行中であることを示しています。

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 55 from 172.16.70.228883

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco Unified Communications Manager（172.16.70.228）から解除要求（DRQ）を受信し、Cisco IOS ゲートキーパーが解除確認（DCF）を Cisco Unified Communications Manager に送信したことを示しています。

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] on sock [0x60AF038C]*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 from 172.16.70.228883

Cisco IOS ゲートキーパーに対する show gatekeeper endpoints コマンドは、4 つの Cisco Unified Communications Manager がすべて Cisco IOS ゲートキーパーに登録されていることを表示します。 このケース スタディのトポロジでは、各クラスタに 2 つずつ、4 つの Cisco Unified Communications Manager があります。 この Cisco IOS ゲートキーパーには 2 つのゾーンがあり、各ゾーンに 2 つの Cisco Unified Communications Manager があります。

R2514-1#show gatekeeper endpoints

                    GATEKEEPER ENDPOINT REGISTRATION                    ===================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type   
--------------- ----- --------------- ----- ---------         ---- 
172.16.70.228       2     172.16.70.228       1493  gka.cisco.com     VOIP-GW
    H323-ID: ac1046e4->ac1046f5
172.16.70.229       2     172.16.70.229        3923  gka.cisco.com     VOIP-GW
    H323-ID: ac1046e5->ac1046f5
172.16.70.245       1     172.16.70.245        1041  gkb.cisco.com     VOIP-GW
    H323-ID: ac1046f5->ac1046e4
172.16.70.243        1     172.16.70.243       2043  gkb.cisco.com     VOIP-GW
    H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4
関連情報
コール フローのトレース

Cisco IOS ゲートウェイのデバッグ メッセージと表示コマンド

ここでは、Cisco IOS ゲートウェイのデバッグ出力と表示コマンドについて説明します。 このケース スタディのトポロジでは、コールが Cisco IOS ゲートウェイを通過します。 Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次の例は、debug voip ccapi inout、debug H225 events、debug H225 asn1 などのコマンドのデバッグ出力です。

次のデバッグ出力では、Cisco IOS ゲートウェイが Cisco Unified Communications Manager（172.16.70.228）からの TCP 接続要求を H.225 のポート 2328 で受け入れています。 

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 172.16.70.228:2328 on socket [1]*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

次のデバッグ出力は、この TCP セッションで、H.225 データが Cisco Unified Communications Manager から着信していることを示しています。 このデバッグ出力には、使用されている H.323 バージョンを表す protocolIdentifier が示されています。 次のデバッグは、H.323 バージョン 2 が使用されていることを示しています。 また、着信側と発呼側の番号も示しています。

- Source Address H323-ID- Destination Address e164
*Mar 12 04:03:57.177:       H225Lib::h225RecvData: Q.931 SETUP received from socket [1]value H323-UserInformation ::= 
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181:   h323-uu-pdu 
*Mar 12 04:03:57.181:   {
*Mar 12 04:03:57.181:     h323-message-body setup : 
*Mar 12 04:03:57.181:       {
*Mar 12 04:03:57.181:         protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181:         sourceAddress 
*Mar 12 04:03:57.181:         {
*Mar 12 04:03:57.181:           h323-ID : "1001"
*Mar 12 04:03:57.181:         },
*Mar 12 04:03:57.185:         destinationAddress 
*Mar 12 04:03:57.185:         {
*Mar 12 04:03:57.185:           e164 : "3333"
*Mar 12 04:03:57.185:         },
*Mar 12 04:03:57.189:       H225Lib::h225RecvData: State changed to [Call Present].

次のデバッグ出力は、Call Control Application Programming Interface（CCAPi）を示しています。 Call Control APi は着信コールを示します。 次の出力では、着信側および発呼側の情報も確認できます。 CCAPi は、デフォルトのダイヤル ピアであるダイヤル ピア 0 に一致します。 CCAPi がダイヤル ピア 0 に一致するのは、発信番号に対する他のダイヤル ピアが見つからず、デフォルトのダイヤル ピアを使用しているためです。 

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, calling=1001, fdest=1 peer_tag=0}, callID=0x616C4838)*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list:  tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, *callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

CCAPi は、ダイヤル ピア 1 と宛先パターン（着信番号 3333）を照合します。 peer_tag はダイヤル ピアを意味します。 要求パケット内の発信側と着信側の番号が示されています。

*Mar 12 04:03:57.193: peer_tag=1*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, callParams={called=3333, calling=1001, fdest=1, voice_peer_tag=1}, mode=0x0)

次のデバッグ出力は、H.225 アラート メッセージが Cisco Unified Communications Manager に返されていることを示しています。 

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, dstCallID=0x12, disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201:   h323-uu-pdu 
*Mar 12 04:03:57.201:   {
*Mar 12 04:03:57.201:     h323-message-body alerting : 
*Mar 12 04:03:57.201:       {
*Mar 12 04:03:57.201:         protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205:         destinationInfo 
*Mar 12 04:03:57.205:         {
*Mar 12 04:03:57.205:           mc FALSE,
*Mar 12 04:03:57.205:           undefinedNode FALSE
*Mar 12 04:03:57.205:         },

このパケットでは、Cisco IOS が H.245 アドレスとポート番号も Cisco Unified Communications Manager に送信しています。 Cisco IOS ゲートウェイは到達不能なアドレスを送信する場合があるため、無音声または片通話になることがあります。

*Mar 12 04:03:57.205:         h245Address ipAddress : *Mar 12 04:03:57.205:           {
*Mar 12 04:03:57.205:             ip 'AC1046E2'H,
*Mar 12 04:03:57.205:             port 011008
*Mar 12 04:03:57.205:           },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213: 
*Mar 12 04:03:57.213:       H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. Call state changed to [Call Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12, dstCallID=0x11, disposition=0, tag=0x0)

次のデバッグ出力は、H.245 セッションが開始されていることを示しています。 コーデック ネゴシエーションの機能表示、各音声パケットに含まれるバイト数を確認できます。

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0xEBFB, fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

次のデバッグ出力は、両方の側が適切にネゴシエートし、160 バイト データの G.711 コーデックで合意したことを示しています。

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323 接続および接続解除のメッセージが後続します。

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373:   h323-uu-pdu 
*Mar 12 04:03:59.373:   {
*Mar 12 04:03:59.373:     h323-message-body connect : 
*Mar 12 04:03:59.373:       {
*Mar 12 04:03:59.373:         protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373:         h245Address ipAddress : 
*Mar 12 04:03:59.373:           {
*Mar 12 04:03:59.377:             ip 'AC1046E2'H,
*Mar 12 04:03:59.377:             port 011008
*Mar 12 04:03:59.377:           },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)
関連情報
Cisco IOS ゲートキーパーのデバッグ メッセージと表示コマンド...

T1/PRI インターフェイスを使用する Cisco IOS ゲートウェイ

上記のように、2 つのタイプのコールが Cisco IOS ゲートウェイを通過します。Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次の例は、Cisco IOS ゲートウェイが T1/PRI インターフェイスを使用する場合のデバッグ出力です。

Cisco IOS ゲートウェイの debug isdn q931 コマンドがオンになり、それにより ISDN 環境にある D チャネル用のレイヤ 3 シグナリング プロトコルである Q.931 がイネーブルになります。 T1/PRI インターフェイスからコールが発信されるたびに、セットアップ パケットが送信される必要があります。 セットアップ パケットには必ずプロトコル記述子 pd = 8 が含まれ、callref 用にランダムな 16 進数値が生成されます。 callref はコールを追跡します。 たとえば、2 つのコールが発信された場合、callref の値によって、RX（受信済み）メッセージの対象になっているコールを判別できます。 ベアラ機能 0x8890 は 64 Kbps のデータ コールです。 これが 0x8890218F だった場合は、56 Kbps のデータ コールになり、音声コールの場合は 0x8090A3 になります。 次のデバッグ出力では、ベアラ機能は 0x8090A3 で、音声に適用されます。 例には、着信側と発呼側の番号が示されています。

callref では、最初の数字に異なる値を使用し（TX と RX を識別するため）、2 番めの値は同じです（SETUP の最後の数字は 0、CONNECT_ACK も 0 です）。 ルータはベアラ チャネル（B チャネル）を割り当てる際に PSTN または PBX に完全に依存します。 PSTN または PBX がルータにチャネルを割り当てないと、コールはルーティングされません。 このケース スタディでは、交換機から受信される CONNECT メッセージに、ALERTING 用に受信されたものと同じ参照番号（0x800B）が含まれています。 最後に、コールが接続解除されるとき、DISCONNECT メッセージの交換後に RELEASE メッセージと RELEASE _COMP メッセージが続くことを確認できます。 RELEASE_COMP メッセージのあとには、コール拒否の理由 ID が続きます。 理由 ID は 16 進数値です。 理由の内容は、16 進数値のデコードとプロバイダーのフォローアップによって確認できます。

 *Mar  1 225209.694 ISDN Se115 TX ->  SETUP pd = 8  callref = 0x000B *Mar  1 225209.694         Bearer Capability i = 0x8090A3
 *Mar  1 225209.694         Channel ID i = 0xA98381
 *Mar  1 225209.694         Calling Party Number i = 0x2183, '1001'
 *Mar  1 225209.694         Called Party Number i = 0x80, '3333'
 *Mar  1 225209.982 ISDN Se115 RX <-  ALERTING pd = 8  callref = 0x800B
 *Mar  1 225209.982         Channel ID i = 0xA98381
 *Mar  1 225210.674 ISDN Se115 RX <-  CONNECT pd = 8  callref = 0x800B
 *Mar  1 225210.678 ISDN Se115 TX ->  CONNECT_ACK pd = 8  callref = 0x000B
 *Mar  1 225215.058 ISDN Se115 RX <-  DISCONNECT pd = 8  callref = 0x800B
 *Mar  1 225215.058         Cause i = 0x8090 - Normal call clearing  225217 %ISDN-6
DISCONNECT Int S10  disconnected from unknown , call lasted 4 sec
 *Mar  1 225215.058 ISDN Se115 TX ->  RELEASE pd = 8  callref = 0x000B
 *Mar  1 225215.082 ISDN Se115 RX <-  RELEASE_COMP pd = 8  callref = 0x800B
*Mar  1 225215.082  Cause i = 0x829F - Normal, unspecified or Special  intercept, call blocked group restriction

T1/CAS インターフェイスを使用する Cisco IOS ゲートウェイ

2 つのタイプのコールが Cisco IOS ゲートウェイを通過します。Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次のデバッグ出力は、Cisco IOS ゲートウェイが T1/CAS インターフェイスを使用する場合に発生します。 Cisco IOS ゲートウェイでは debug cas がオンになっています。

次のデバッグ メッセージは、Cisco IOS ゲートウェイがオフフック信号を交換機に送信していることを示しています。 

Apr  5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111)

次のデバッグ メッセージは、交換機が Cisco IOS ゲートウェイから閉ループ信号を受信後、ウィンクを送信していることを示しています。

Apr  5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)Apr  5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

次のデバッグ メッセージは、Cisco IOS ゲートウェイがオフフックしようとしていることを示しています。

Apr  5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

次の出力は、コールが進行中の Cisco IOS ゲートウェイでの show call active voice brief を示しています。 出力には、着信側と発呼側の番号およびその他の役立つ情報も示されています。

R5300-5#show call active voice brief<ID>: <start>hs.<index> +<connect> pid:<peer_id> <dir> <addr> <state> tx:<packets>/<bytes> rx:<packets>/<bytes> <state>
 IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>  delay:<last>/<min>/<max>ms <codec>
 FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
 Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
 tx:1752/280320 rx:988/158080
 IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
 tx:988/136972 rx:1759/302548
 Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0  i/0:-36/-42 dBm

このケース スタディでは、ローカル PBX を経由して接続している電話機、または公衆電話交換網（PSTN）上の電話機に、Cisco IOS ゲートウェイを経由してコールを発信する Cisco Unified IP Phone について説明します。 概念的には、コールが Cisco IOS ゲートウェイに到達すると、ゲートウェイはそのコールを FXS ポートまたは PBX に接続された電話機のいずれかに転送します。 PBX に転送されたコールは、ローカル PBX に接続された電話機で終端するか、または PBX によって PSTN 経由で転送され、PSTN 上で終端します。

関連情報

コール フローのトレース

ここでは、Cisco Communications Manager トレース ファイル CCM000000000 の例を使用してコール フローについて説明します。 このケース スタディのトレースでは、コール フロー自体に焦点を絞っています。 詳細なトレース情報については、Cisco Unified IP Phone コールに関連するトピックを参照してください（たとえば、初期化、登録、およびキープアライブ メカニズムなど）。

このコール フローでは、Cluster 2 にある Cisco Unified IP Phone（電話番号 1001）が PSTN 上の電話機（電話番号 3333）にコールを発信します。 トレースでデバイスを追跡するには、デバイスの TCP ハンドル値、タイムスタンプ、または名前を調べます。 デバイスの TCP ハンドル値は、デバイスがリブートされるかオフラインになるまで変わりません。

次のトレースでは、Cisco Unified IP Phone（1001）がオフフックになっています。 トレースは、Cisco Unified IP Phone に表示される固有のメッセージ、TCP ハンドル、発信番号を示しています。 ユーザはまだ番号をダイヤルしていないため、この時点では着信番号は表示されていません。

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001

次のトレースでは、ユーザが DN 3333 をダイヤルしています（数字を 1 つずつダイヤルします）。 番号 3333 は、PSTN ネットワーク上の電話機の宛先番号です。 Cisco Unified Communications Manager の番号分析プロセスが現在アクティブになっており、コールのルーティング先を検出するために番号を分析しています。 番号分析の詳細については、Cisco Unified IP Phone コールに関連するトピックを参照してください。

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

次のトレースでは、番号分析が完了して発信側と着信側が一致し、情報が解析されています。

|CallingPartyNumber=1001|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

次のトレースでは、番号 0 が発信元のロケーションを示し、番号 1 が宛先のロケーションを示しています。 BW = -1 は、発信元のロケーションの帯域幅を示します。 値 -1 は、帯域幅が無限であることを暗黙的に示します。 コールは LAN 環境にある Cisco Unified IP Phone から発信されたため、帯域幅は無限であると見なされます。 BW = 64 は、宛先のロケーションの帯域幅を示します。 コールの宛先は PSTN 上にある電話機で、使用されるコーデック タイプは G.711（64 Kbps）です。

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

次のトレースは、発信側および着信側の情報を示しています。 この例では、管理者が表示名（John Smith など）を設定していないため、発呼側の名前と番号は同じです。

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98

次のトレースは、H.323 コードが初期化され、H.225 セットアップ メッセージを送信していることを示しています。 従来の HDLC SAPI メッセージ、16 進表記の着信側の IP アドレス、およびポート番号も確認できます。

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol15:20:21.421 CCM|MMan_Id= 1. (iep=  0 dsl=  0 sapi=  0 ces=  0 IpAddr=e24610ac IpPort=47110)

次のトレースは、発信側および着信側の情報と H.225 アラート メッセージを示しています。 また、Cisco Unified IP Phone の 16 進数値と IP アドレスのマッピングも示されています。 Cisco Unified IP Phone（1001）の IP アドレスは 172.16.70.231 です。

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d9815:20:21.453 CCM|In  Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)

次のトレースは、このコールで使用されている圧縮タイプ（G.711 mu-law）を示しています。

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k

H.323 は H.225 アラート メッセージが送信されたあとで、H.245 を初期化します。 次のトレースは、発信側および着信側の情報と H.245 メッセージを示しています。 TCP ハンドル値はこれまでと同じで、同じコールが続いていることを示しています。

ONE FOR EACH Channel- 16:53:36.855 CCM|H245Interface(3) paths established ip = e98e6b80, port = 1304|<CT::1,100,105,1.1682><IP::128.107.142.233>ONE FOR EACH Channel- 16:53:37.199 CCM|H245Interface(3) OLC outgoing confirm ip = b870701, port = 49252|<CT::1,100,128,3.9><IP::1.7.135.11>
 
H323 EP has answered the call and H245 channel setup in progress:
16:53:13.479 CCM|In  Message -- H225ConnectMsg -- Protocol= H225Protocol|
 
16:03:25.359 CCM|StationD(1):  TCPPid = [1.100.117.1] CallInfo callingPartyName='' callingParty=13001 cgpnVoiceMailbox=    calledPartyName='' calledParty=11002 cdpnVoiceMailbox=    originalCalledPartyName='' originalCalledParty=11002 originalCdpnVoiceMailbox= originalCdpnRedirectReason=0    lastRedirectingPartyName='' lastRedirectingParty=11002 lastRedirectingVoiceMailbox= lastRedirectingReason=0    callType=2(OutBound) lineInstance=1 callReference=16777217. version: 0|<CT::1,100,11,2.1><IP::><DEV::>
 
16:03:25.328 CCM|StationD(1):   TCPPid = [1.100.117.1] OpenReceiveChannel conferenceID=16777217 passThruPartyID=16777233 millisecondPacketSize=20    compressionType=4(Media_Payload_G711Ulaw64k) qualifierIn=?. myIP: e98e6b80 (128.107.142.233)|<CT::1,100,11,1.1><IP::><DEV::>
16:03:25.359 CCM|StationD(2):   TCPPid = [1.100.117.2] StartMediaTransmission conferenceID=16777218 passThruPartyID=16777249 remoteIpAddress=e98e6b80(64.255.0.0)    remotePortNumber=65344 milliSecondPacketSize=20 compressType=4(Media_Payload_G711Ulaw64k) qualifierOut=?. myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.213><IP::128.107.142.233>
16:03:25.375 CCM|StationD(2):   TCPPid = [1.100.117.2] star_StationOutputStartMultiMediaTransmission conferenceID=16777218 passThruPartyID=16777250 remoteIpAddress=e98e6b80(66.255.0.0)    remotePortNumber=65346 compressType=101(Media_Payload_H263) qualifierOut=?. myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.215><IP::128.107.142.233>
16:03:25.328 CCM|StationD(1):   TCPPid=[1.100.117.1] OpenMultiReceiveChannel conferenceID=16777217 passThruPartyID=1000011 compressionType=101(Media_Payload_H263) qualifierIn=?.   myIP: e98e6b80 (128.107.142.233)|<CT::1,100,11,1.1><IP::><DEV::>

次のトレースは、H.225 接続メッセージとその他の情報を示しています。 H.225 接続メッセージが受信されると、コールが接続します。

15:20:22.968 CCM|In  Message -- H225ConnectMsg -- Protocol= H225Protocol15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 16758 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)
16:03:25.359 CCM|MediaManager(1) - wait_AuConnectInfo - recieved response, fowarding, CI(16777217,16777218)|<CT::1,100,105,1.213><IP::128.107.142.233>
16:03:25.359 CCM|MediaCoordinator - wait_AuConnectInfoInd|<CT::1,100,105,1.213><IP::128.107.142.233>
16:03:25.359 CCM|ConnectionManager - wait_AuConnectInfoInd, CI(16777217,16777218)|<CT::1,100,105,1.213><IP::128.107.142.233>

次のメッセージは、Cisco Unified IP Phone（1001）からのオンフック メッセージを受信していることを示しています。 オンフック メッセージを受信するとすぐに、H.225 と Skinny Station デバイスの接続解除メッセージが送信され、H.225 メッセージの全文が表示されます。 この最後のメッセージには、コールが終端したことが示されています。

15:20:27.296 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x5138d9815:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to (64,5) and remove connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:28.328 CCM|In  Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:03:33.344 CCM|StationInit - InboundStim - StationOnHookMessageID: Msg Size(received, defined) = 4, 12|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|ConnectionManager - wait_AuDisconnectRequest(16777217,16777218): STOP SESSION|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] CloseReceiveChannel conferenceID=16777218 passThruPartyID=16777249.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] StopMediaTransmission conferenceID=16777218 passThruPartyID=16777249.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] star_StationOutputCloseMultiMediaReceiveChannel conferenceID=16777218 passThruPartyID=16777249.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
16:03:33.359 CCM|StationD(2):   TCPPid = [1.100.117.2] star_StationOutputStopMultiMediaTransmission conferenceID=16777218 passThruPartyID=16777250.  myIP: e98e6b80 (128.107.142.233)|<CT::1,100,105,1.219><IP::128.107.142.233>
関連情報

Cisco IOS ゲートキーパーのデバッグ メッセージと表示コマンド

このケース スタディのトポロジでは、Cisco IOS ゲートキーパーで debug ras コマンドがオンになっています。 SDI トレースの詳細については、コール フロー トレースに関するトピックを参照してください。

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco Unified Communications Manager（172.16.70.228）に対するアドミッション要求（ARQ）を受信し、その他の正常なリモート アクセス サーバ（RAS）メッセージが後続していることを示しています。 最後に、Cisco IOS ゲートキーパーがアドミッション確認（ACF）メッセージを Cisco Unified Communications Manager に送信しています。

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] on sock [0x60AF038C]*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

次のデバッグ メッセージは、コールが進行中であることを示しています。

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 55 from 172.16.70.228883

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco Unified Communications Manager（172.16.70.228）から解除要求（DRQ）を受信し、Cisco IOS ゲートキーパーが解除確認（DCF）を Cisco Unified Communications Manager に送信したことを示しています。

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] on sock [0x60AF038C]*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 from 172.16.70.228883

Cisco IOS ゲートキーパーに対する show gatekeeper endpoints コマンドは、4 つの Cisco Unified Communications Manager がすべて Cisco IOS ゲートキーパーに登録されていることを表示します。 このケース スタディのトポロジでは、各クラスタに 2 つずつ、4 つの Cisco Unified Communications Manager があります。 この Cisco IOS ゲートキーパーには 2 つのゾーンがあり、各ゾーンに 2 つの Cisco Unified Communications Manager があります。

R2514-1#show gatekeeper endpoints

                    GATEKEEPER ENDPOINT REGISTRATION                    ===================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type   
--------------- ----- --------------- ----- ---------         ---- 
172.16.70.228       2     172.16.70.228       1493  gka.cisco.com     VOIP-GW
    H323-ID: ac1046e4->ac1046f5
172.16.70.229       2     172.16.70.229        3923  gka.cisco.com     VOIP-GW
    H323-ID: ac1046e5->ac1046f5
172.16.70.245       1     172.16.70.245        1041  gkb.cisco.com     VOIP-GW
    H323-ID: ac1046f5->ac1046e4
172.16.70.243        1     172.16.70.243       2043  gkb.cisco.com     VOIP-GW
    H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4
関連情報

Cisco IOS ゲートウェイのデバッグ メッセージと表示コマンド

ここでは、Cisco IOS ゲートウェイのデバッグ出力と表示コマンドについて説明します。 このケース スタディのトポロジでは、コールが Cisco IOS ゲートウェイを通過します。 Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次の例は、debug voip ccapi inout、debug H225 events、debug H225 asn1 などのコマンドのデバッグ出力です。

次のデバッグ出力では、Cisco IOS ゲートウェイが Cisco Unified Communications Manager（172.16.70.228）からの TCP 接続要求を H.225 のポート 2328 で受け入れています。 

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 172.16.70.228:2328 on socket [1]*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

次のデバッグ出力は、この TCP セッションで、H.225 データが Cisco Unified Communications Manager から着信していることを示しています。 このデバッグ出力には、使用されている H.323 バージョンを表す protocolIdentifier が示されています。 次のデバッグは、H.323 バージョン 2 が使用されていることを示しています。 また、着信側と発呼側の番号も示しています。

- Source Address H323-ID- Destination Address e164
*Mar 12 04:03:57.177:       H225Lib::h225RecvData: Q.931 SETUP received from socket [1]value H323-UserInformation ::= 
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181:   h323-uu-pdu 
*Mar 12 04:03:57.181:   {
*Mar 12 04:03:57.181:     h323-message-body setup : 
*Mar 12 04:03:57.181:       {
*Mar 12 04:03:57.181:         protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181:         sourceAddress 
*Mar 12 04:03:57.181:         {
*Mar 12 04:03:57.181:           h323-ID : "1001"
*Mar 12 04:03:57.181:         },
*Mar 12 04:03:57.185:         destinationAddress 
*Mar 12 04:03:57.185:         {
*Mar 12 04:03:57.185:           e164 : "3333"
*Mar 12 04:03:57.185:         },
*Mar 12 04:03:57.189:       H225Lib::h225RecvData: State changed to [Call Present].

次のデバッグ出力は、Call Control Application Programming Interface（CCAPi）を示しています。 Call Control APi は着信コールを示します。 次の出力では、着信側および発呼側の情報も確認できます。 CCAPi は、デフォルトのダイヤル ピアであるダイヤル ピア 0 に一致します。 CCAPi がダイヤル ピア 0 に一致するのは、発信番号に対する他のダイヤル ピアが見つからず、デフォルトのダイヤル ピアを使用しているためです。 

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, calling=1001, fdest=1 peer_tag=0}, callID=0x616C4838)*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list:  tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, *callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

CCAPi は、ダイヤル ピア 1 と宛先パターン（着信番号 3333）を照合します。 peer_tag はダイヤル ピアを意味します。 要求パケット内の発信側と着信側の番号が示されています。

*Mar 12 04:03:57.193: peer_tag=1*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, callParams={called=3333, calling=1001, fdest=1, voice_peer_tag=1}, mode=0x0)

次のデバッグ出力は、H.225 アラート メッセージが Cisco Unified Communications Manager に返されていることを示しています。 

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, dstCallID=0x12, disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201:   h323-uu-pdu 
*Mar 12 04:03:57.201:   {
*Mar 12 04:03:57.201:     h323-message-body alerting : 
*Mar 12 04:03:57.201:       {
*Mar 12 04:03:57.201:         protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205:         destinationInfo 
*Mar 12 04:03:57.205:         {
*Mar 12 04:03:57.205:           mc FALSE,
*Mar 12 04:03:57.205:           undefinedNode FALSE
*Mar 12 04:03:57.205:         },

このパケットでは、Cisco IOS が H.245 アドレスとポート番号も Cisco Unified Communications Manager に送信しています。 Cisco IOS ゲートウェイは到達不能なアドレスを送信する場合があるため、無音声または片通話になることがあります。

*Mar 12 04:03:57.205:         h245Address ipAddress : *Mar 12 04:03:57.205:           {
*Mar 12 04:03:57.205:             ip 'AC1046E2'H,
*Mar 12 04:03:57.205:             port 011008
*Mar 12 04:03:57.205:           },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213: 
*Mar 12 04:03:57.213:       H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. Call state changed to [Call Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12, dstCallID=0x11, disposition=0, tag=0x0)

次のデバッグ出力は、H.245 セッションが開始されていることを示しています。 コーデック ネゴシエーションの機能表示、各音声パケットに含まれるバイト数を確認できます。

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0xEBFB, fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

次のデバッグ出力は、両方の側が適切にネゴシエートし、160 バイト データの G.711 コーデックで合意したことを示しています。

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323 接続および接続解除のメッセージが後続します。

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373:   h323-uu-pdu 
*Mar 12 04:03:59.373:   {
*Mar 12 04:03:59.373:     h323-message-body connect : 
*Mar 12 04:03:59.373:       {
*Mar 12 04:03:59.373:         protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373:         h245Address ipAddress : 
*Mar 12 04:03:59.373:           {
*Mar 12 04:03:59.377:             ip 'AC1046E2'H,
*Mar 12 04:03:59.377:             port 011008
*Mar 12 04:03:59.377:           },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)
関連情報

T1/PRI インターフェイスを使用する Cisco IOS ゲートウェイ

上記のように、2 つのタイプのコールが Cisco IOS ゲートウェイを通過します。Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次の例は、Cisco IOS ゲートウェイが T1/PRI インターフェイスを使用する場合のデバッグ出力です。

Cisco IOS ゲートウェイの debug isdn q931 コマンドがオンになり、それにより ISDN 環境にある D チャネル用のレイヤ 3 シグナリング プロトコルである Q.931 がイネーブルになります。 T1/PRI インターフェイスからコールが発信されるたびに、セットアップ パケットが送信される必要があります。 セットアップ パケットには必ずプロトコル記述子 pd = 8 が含まれ、callref 用にランダムな 16 進数値が生成されます。 callref はコールを追跡します。 たとえば、2 つのコールが発信された場合、callref の値によって、RX（受信済み）メッセージの対象になっているコールを判別できます。 ベアラ機能 0x8890 は 64 Kbps のデータ コールです。 これが 0x8890218F だった場合は、56 Kbps のデータ コールになり、音声コールの場合は 0x8090A3 になります。 次のデバッグ出力では、ベアラ機能は 0x8090A3 で、音声に適用されます。 例には、着信側と発呼側の番号が示されています。

callref では、最初の数字に異なる値を使用し（TX と RX を識別するため）、2 番めの値は同じです（SETUP の最後の数字は 0、CONNECT_ACK も 0 です）。 ルータはベアラ チャネル（B チャネル）を割り当てる際に PSTN または PBX に完全に依存します。 PSTN または PBX がルータにチャネルを割り当てないと、コールはルーティングされません。 このケース スタディでは、交換機から受信される CONNECT メッセージに、ALERTING 用に受信されたものと同じ参照番号（0x800B）が含まれています。 最後に、コールが接続解除されるとき、DISCONNECT メッセージの交換後に RELEASE メッセージと RELEASE _COMP メッセージが続くことを確認できます。 RELEASE_COMP メッセージのあとには、コール拒否の理由 ID が続きます。 理由 ID は 16 進数値です。 理由の内容は、16 進数値のデコードとプロバイダーのフォローアップによって確認できます。

 *Mar  1 225209.694 ISDN Se115 TX ->  SETUP pd = 8  callref = 0x000B *Mar  1 225209.694         Bearer Capability i = 0x8090A3
 *Mar  1 225209.694         Channel ID i = 0xA98381
 *Mar  1 225209.694         Calling Party Number i = 0x2183, '1001'
 *Mar  1 225209.694         Called Party Number i = 0x80, '3333'
 *Mar  1 225209.982 ISDN Se115 RX <-  ALERTING pd = 8  callref = 0x800B
 *Mar  1 225209.982         Channel ID i = 0xA98381
 *Mar  1 225210.674 ISDN Se115 RX <-  CONNECT pd = 8  callref = 0x800B
 *Mar  1 225210.678 ISDN Se115 TX ->  CONNECT_ACK pd = 8  callref = 0x000B
 *Mar  1 225215.058 ISDN Se115 RX <-  DISCONNECT pd = 8  callref = 0x800B
 *Mar  1 225215.058         Cause i = 0x8090 - Normal call clearing  225217 %ISDN-6
DISCONNECT Int S10  disconnected from unknown , call lasted 4 sec
 *Mar  1 225215.058 ISDN Se115 TX ->  RELEASE pd = 8  callref = 0x000B
 *Mar  1 225215.082 ISDN Se115 RX <-  RELEASE_COMP pd = 8  callref = 0x800B
*Mar  1 225215.082  Cause i = 0x829F - Normal, unspecified or Special  intercept, call blocked group restriction

T1/CAS インターフェイスを使用する Cisco IOS ゲートウェイ

2 つのタイプのコールが Cisco IOS ゲートウェイを通過します。Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次のデバッグ出力は、Cisco IOS ゲートウェイが T1/CAS インターフェイスを使用する場合に発生します。 Cisco IOS ゲートウェイでは debug cas がオンになっています。

次のデバッグ メッセージは、Cisco IOS ゲートウェイがオフフック信号を交換機に送信していることを示しています。 

Apr  5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111)

次のデバッグ メッセージは、交換機が Cisco IOS ゲートウェイから閉ループ信号を受信後、ウィンクを送信していることを示しています。

Apr  5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)Apr  5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

次のデバッグ メッセージは、Cisco IOS ゲートウェイがオフフックしようとしていることを示しています。

Apr  5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

次の出力は、コールが進行中の Cisco IOS ゲートウェイでの show call active voice brief を示しています。 出力には、着信側と発呼側の番号およびその他の役立つ情報も示されています。

R5300-5#show call active voice brief<ID>: <start>hs.<index> +<connect> pid:<peer_id> <dir> <addr> <state> tx:<packets>/<bytes> rx:<packets>/<bytes> <state>
 IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>  delay:<last>/<min>/<max>ms <codec>
 FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
 Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
 tx:1752/280320 rx:988/158080
 IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
 tx:988/136972 rx:1759/302548
 Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0  i/0:-36/-42 dBm

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

Feedbackフィードバック

シスコに問い合わせ