音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

Cisco CallManager を使ったレガシー音声メールの統合に関するトラブルシューティング

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、レガシー ボイス メッセージング システムと、Simplified Message Desk Interface(SMDI)および Digital PBX Adaptor(DPA)7630/7610 を使用する Cisco CallManager との統合に関するトラブルシューティングについて説明します。

前提条件

要件

このドキュメントの読者は次のトピックについて理解している必要があります。

  • Cisco CallManager 3.x または 4.x

  • Telcordia GR 283-core 問題 2 (SMDI)

  • Octel音声メール、該当する場合(DPA -7630/7610)

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco CallManager 3.x および 4.x

  • Cisco MCS-7835

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

Cisco Unified CallManager との SMDI 統合

Cisco Messaging Interface はレガシー 音声 メール プラットフォームが SMDI の使用と Cisco Unified CallManager に接続するようにする Cisco Unified CallManager 内のサービスです。 Cisco Messaging Interface は着信側および発信側についてのレガシー音声メールシステムにコールがなぜ示される、ポートが音声メールシステム コールを待ちか情報を、原因提供します。 これは音声メールシステムがコールに正しく応答するようにします。

SMDI の 2 つのコール タイプがあります:

  • ダイレクト コール

  • 転送された コール

ダイレクト コール 形式

ダイレクト コール SMDI 形式は次のとおりです:

  • <CR><LF>MDXXXLLLLT<0x20>YYYY<0x20><CR><LF><^Y>

<CR> 復帰
<LF> ライン フィード
MDXXX メッセージ デスク。 これは 3 Digits フィールド、通常 001 です
LLLL Logical Terminal Number (0001 か。 4096)
T 理由コード- D 等号ダイレクト コール
<0x20> 領域
YYYY 発番号
<0x20> 領域
<CR> 復帰
<LF> ライン フィード
<^Y> メディア終端

これは拡張 2000 年からのダイレクト コールの例です。 それは LTN 0002 の音声メッセージシステム、かポート 2.に示されました。

  • 2000 0002 <CR><LF>MD001 D<0x20> <0x20><CR><LF><^Y>

ダイレクト コールをトラブルシュートして下さい

発信者がダイレクト コールを送信するとき、発信者はパスワードを入力するためにプロンプト表示されると期待します。 音声メールシステムに、ゲートウェイ、Route リストおよびルート グループは SMDI によって音声メールシステムへの統合のための Cisco CallManager 3.0(x) の設定で発生するそれのために記述します設定する必要があります。 ダイレクト コールのためのもっとも一般的な原因は失敗するメッセージ デスクまたは Logical Terminal Number (LTN)間のミスコンフィギュレーションです。 Cisco Messaging Interface は 001 のメッセージ デスクをデフォルトで使用します。 構内交換機 (PBX) ベンダーか Central Office (CO)によって別のメッセージ デスクを与えられる場合、Cisco Messaging Interface 設定でそれを規定 して下さい。

smdi-1.gif

MessageDeskNumber が正しい場合、LTN が正しいことを確認して下さい。 Cisco Unified CallManager 側で、LTN はルート グループで設定したポートに一致します。 最初のポートは LTN 1、第 2 ポートです LTN 2、等です。 こういうわけで統合のための Cisco CallManager 3.0(x) を SMDI によって音声メールシステムに設定するのでポートおよび順序ドロップダウンを設定することは必要記述しますです。 すべてのポートが選択される場合、Cisco Messaging Interface によって生成される LTN は LTN 1.です。 これは壊れる統合という結果に終ります。 音声メール側で、ケーブル接続がゲートウェイと音声メールポート間で正しいことを確認することは必要です。 どのポート(LTN)をコールが音声メールシステムに示されているか SMDI メッセージが示すので、すべてのレイヤ1 問題は解決されなければなりません。

音声メールへのダイレクト コールがなぜ失敗するか第 2 一般的 な 原因は Cisco Messaging Interface の VoiceMailPartition フィールドのミスコンフィギュレーションです。

/image/gif/paws/18779/smdi-2.gif

VoiceMailPartition フィールドは音声メールにルートパターンに Route リストへのそのポイント割り当てられるパーティションの名前が含まれている必要があります。 この情報が不正確である場合、VoiceMailDn のための代行受信するは引き起こされないし、SMDI メッセージは生成されません。 その結果、音声メールシステムに望まれるようにコールを処理する適切な情報および一般的 なメッセージを用いる返事がありません。

音声メールシステムがこれに頼る場合 SMDIリンクが音声メール側に稼働していることを確認して下さい。 Cisco Unified CallManager は意味する標準 PC で動作します、シリアルポートに実際に配線される 9 本のピンがあることを。 ただし、Cisco Messaging Interface は RS-232 行の 3 つを使用します: TD、RD および GND。 2 つの送信 制御線があります: RTS および DTR。 これらは両方行が無視されるかどうかポートがオープンになるが、Cisco Messaging Interface が気遣わないときアサートされます。 4 つの着信 制御線があります: DCD、CTS、DSR および RI。 これらの行すべてはまた無視されます。

CMI からのダイレクト コール トレース

トラブルシューティングのために SMDI においての、検査します C にある Cisco Messaging Interface トレースファイルを発行します: /Program ファイル/Cisco/Trace/CMI ディレクトリ。

19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg userdata = 5996360, Key = 7864, DSL2 = 2,
calledparty =3500, callingparty =2000
19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Direct Call port - 2, callingparty -2000
19:27:58.578 Cisco Messaging Interface|-->CMISsapiClient::SendDirectCall()
19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::SendDirectCall()

これは拡張 2000 年からのダイレクト コールの例です。 それは LTN 0002 の音声メッセージシステム、かポート 2.に示されました。

  • 送信ダイレクト コール: 2000 [<CR><LF>MD0010002D<0x20> <0x20><CR><LF><^Y>]

Cisco Messaging Interface は VoiceMailDn を代行受信し、SMDI メッセージを生成すること検証すればメッセージが受け取られるようにするために、音声メール ベンダーとはたらくことができます。 音声メールシステムが SMDI メッセージを受け取らない場合、Cisco Messaging Interface がそれらを生成するのに、ハイパーターミナルがある PC が Cisco CallManager サーバを去るかどうか示すのに使用することができます。

転送された コール 形式

Cisco CallManager 3.0 はすべての呼び出しのための A の前方理由コードを順方向にサポートします。 Cisco CallManager 3.1 およびそれ以降では、理由コード B および N は使用中および返事のために、それぞれ追加されません。

転送された コール 形式は次のとおりです:

  • <CR><LF>MDXXXLLLLTDDDDDDD<0x20>CCCCCCC<0x20><CR><LF><^Y>

<CR> 復帰
<LF> ライン フィード
MDXXX メッセージ デスク。 第 xxx は普通 001 です
LLLL Logical Terminal Number (0001 - 4096)
T コール タイプ。 A は転送されるすべての呼び出しです(CM によって 3.0)サポートされて、B は使用中前方です(3.1) CM は Ring No Answer (3.1) CM のため、N です
DDDDDDD 被呼加入者
<0x20> 領域
CCCCCCC コーリングパーティ
<0x20> 領域
<CR> 復帰
<LF> ライン フィード
<EM> メディア終端

これは拡張へ拡張からの転送された コールの 2001 2000 例です。 コールは音声メールに被呼加入者の電話が Call forward all 状態にあるので発信されます。 コールは LTN の音声メッセージシステム、かポート 2.に 0002 示されます。

  • 2000 2001 0002 [<CR><LF>MD001 A <0x20> <0x20><CR><LF><^Y>]

転送された コールをトラブルシュートして下さい

発信者が他のパーティにコールを送信し、音声メールに転送されるとき、予期はそれらが被呼加入者のメッセージを受け取ることです。 音声メールシステムに、ゲートウェイは SMDI によって音声メールシステムへの統合のための Cisco CallManager 3.0(x) の設定に記述されているように発生するそれのために設定する必要があります。 転送された コールをトラブルシュートすることを試みる前にダイレクト コールがはたらくようにして下さい。

転送された コールをトラブルシュートするとき、レガシー音声メールシステムが転送された理由コードをサポートするようにするためにチェックして下さい。 いくつかの音声メールシステムはさまざまな理由コードのプログラミングを可能にします。 場合によっては Cisco Unified CallManager がバージョン 3.1 の前に配置されたところで、音声メールシステムは Cisco Unified CallManager がそれらをその当時サポートしなかったので使用中のおよび返事によって転送される理由コードを受け入れないためにプログラムされないかもしれません。

Cisco Messaging Interface からの転送された コール トレース

SMDI で問題を解決するとき、C にある Cisco Messaging Interface トレースファイルを検査して下さい: /Program ファイル/Cisco/Trace/CMI ディレクトリ。

18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg fOriginalCdpn = 2001, fCgpn = 2000 fCallingPattern
= 2000
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg userdata = 5996336, Key = 7864, DSL2 = 2,
calledparty = 2001, callingparty = 2000
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Forwarded Call port - 2, calledparty - 2001, callingparty - 2000
18:33:28.187 Cisco Messaging Interface|-->CMISsapiClient::SendCallForwardAll()
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::SendCallForwardAll()
Send call forward all: [<CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>]
18:33:28.187 Cisco Messaging Interface|-->CMISerialWorker::SendBuffer()
18:33:28.187 Cisco Messaging Interface|   CMISerialWorker::SendBuffer()
Send Buffer - <CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>
18:33:28.197 Cisco Messaging Interface|<--CMISerialWorker::SendBuffer()
18:33:28.197 Cisco Messaging Interface|<--CMISsapiClient::SendCallForwardAll()

これは拡張へ拡張からの転送された コールの 2001 2000 例です。 コールは音声メールに被呼加入者の電話が Call forward all 状態にあるので発信されます。 コールは LTN の音声メッセージシステム、かポート 2.に 0002 示されます。

Cisco Messaging Interface は VoiceMailDn を代行受信し、SMDI メッセージを生成すること検証すればメッセージが受け取られるようにするために、音声メール ベンダーとはたらくことができます。 音声メールシステムが SMDI メッセージを受け取らない場合、Cisco Messaging Interface がそれらを生成するのに、ハイパーターミナルがある PC が Cisco CallManager サーバを去っているかどうか示すのに使用することができます。

MWI 形式

不規則なコマンドを待っているメッセージのための形式は次のとおりです:

MWI オン:

OP: MWI メッセージ待機インディケーターを操作して下さい
<0x20> 領域
XXXX 拡張番号
<EOT> End of Transmission

OP:MWI<0x20>2001!<EOT>

メッセージ待っている拡張 2001 年をつける要求。

MWI オフ:

RMV: MWI メッセージ待機インディケーターを取除いて下さい
<0x20> 領域
XXXX 拡張番号
<EOT> End of Transmission

RMV:MWI<0x20>2001!<EOT>

メッセージ待っている拡張 2001 年を消す要求。

MWI を解決して下さい

SMDI で MWI 問題を解決するとき、第一歩は要求が Cisco Unified CallManager によって受け取られるかどうか判別しますあります。 C にある Cisco Messaging Interface トレースファイル: SMDI メッセージが音声メールシステムによって送信 され、Cisco Unified CallManager によって受け取られるかどうか /Program ファイル/Cisco/Trace/CMI は明らかにします。

要求が Cisco Unified CallManager によって受け取られるが、MWI が正しくはたらかない場合、Cisco Messaging Interface の MWI SearchSpace フィールドがランプがオン/オフ回るように要求されている電話に属するパーティションが含まれていることを確認して下さい。 MWISearchSpace フィールドはコロンで分かれるパーティションの名前が含まれている必要があります。 このフィールドは大文字/小文字の区別があります。

/image/gif/paws/18779/smdi-3.gif

Cisco Messaging Interface からの MWI トレース

MWI On

18:33:47.846 Cisco Messaging Interface|   CMISerialWorker::SerialThread()
Saw EOT, inbound message: [OP:MWI<0x20>2001!<EOT>]
18:33:47.846 Cisco Messaging Interface|-->CMISsapiClient::OnLampOn()
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOn()
Lamp On - 2001
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOn()
Processed number = 2001
18:33:47.906 Cisco Messaging Interface|<--CMISsapiClient::OnLampOn()

MWI Off

18:33:47.846 Cisco Messaging Interface|   CMISerialWorker::SerialThread()
Saw EOT, inbound message: [RMV:MWI<0x20>2001!<EOT>]
18:33:47.846 Cisco Messaging Interface|-->CMISsapiClient::OnLampOff()
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOff()
Lamp Off - 2001
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOff()
Processed number = 2001
18:33:47.906 Cisco Messaging Interface|<--CMISsapiClient::OnLampOff()

既知の問題

  • 6624 ブレードのおよびゲートウェイ x の FXS ポートはタイムリーにオンフックに行きません。

    これらのデバイスのデフォルトの動作はそれらがリオーダー トーンを受け取るときオンフックに行くことです。 ただし、多くの音声メールシステムは追加注文します、むしろダイヤルトーン切りません。 ゲートウェイの動作を変更するために 5000 のデフォルト値から 1234 にコール リスタート タイマーを修正できます。

    /image/gif/paws/18779/smdi-4.gif

  • イベント ビューアの Cisco Messaging Interface についてのエラーメッセージ。

    Error:  CMyProcessConfigList::GetSafeIntegerParam() catch 
    handler Parameter MessageDeskNumber not found in database, using 
    default value of 1. 

    Cisco Unified CallManager の以前のリリースでは、メッセージ デスク パラメータは 1.にハードコードでした。 Cisco CallManager 3.0(7)では、設定可能なメッセージ デスク数のためのサポートは導入されました。 メッセージ デスク数を定義しない場合、Cisco Unified CallManager はメッセージ デスク 1.を使用します。

  • Cisco Messaging Interface はとどまり動作します。

    Cisco CallManager 3.0(7)のリリースによって、VoiceMailDN フィールドが必要となります。

  • Octel が複数の SMDIリンクを使用する時 Octel 250/350 の MWI 無し。

    Octel音声 メールシステムが複数の SMDIリンクを使用するとき、どのリンクがに規定 することは必要 MWI コマンドは送信 されることを必要とするかです。 メールボックス プロファイルでは、Int を編集できます Cisco Unified CallManager に Octel を接続する SMDIリンクに対応するリンク番号 フィールド。

Cisco DPA 7630/7610

Cisco DPA 76xx 音声 メールゲートウェイは Cisco IP Telephony ソリューションにネットワークを接続することをレガシー 音声 メール 機器が可能にする VOIPゲートウェイです。 Cisco DPA 7610 は Nortel Meridian 1 PBX に接続するのに現在 デジタル ステーション エミュレーションを使用する Octel音声 メールシステムが代りに Cisco IP に CallManagerシステムを接続するようにします。 Cisco DPA 7630 は Avaya に Definity PBX を接続するのに現在 デジタル ステーション エミュレーションを使用する Octel音声 メールシステムが代りに音声メールシステムへの変更なしで Cisco IP に CallManagerシステムを接続するようにします。

Cisco Unified CallManager は 30 VIP の収集が電話をかけ、PBX の Avaya G3 が 7504D デジタル電話の収集として DPA を見ると同時に Cisco DPA 76xx を表示します。 Nortel Meridian M1 は 2616 の電話機の収集として DPA を見ます。

Cisco DPA 7630/7610 を通して音声メールに呼び出しをトラブルシュートして下さい

Cisco DPA 76xx ゲートウェイに非常に精密な配線必要条件があります。 Cisco DPA76xx で問題を解決するときケーブル接続を確認することは必要です。

レイヤ1 問題は解決されることを確認していれば、これらの推奨事項を調査できます。

  • 症状: リオーダー トーンは発信者にコールが音声メールに送信されるとき再生されます。

    • 提案: DPA が 12 のポートを越えて設定される場合、第 13 発信者は最初の 12 のポートが使用中である場合追加注文します受け取ることができます。 Cisco Unified CallManager に ForwardMaximumHopCount とよばれるサービスパラメータがあります。 デフォルトで、このフィールドは 12 という値に設定 されます。

      /image/gif/paws/18779/smdi-5.gif

      DPA で設定されるポートの数にこの値を設定 して下さい。

  • 症状: 発信者はサブスクライバのメールボックスのためのメッセージよりもむしろ main greeting (開いたツリー)を得ます。

    • 提案: DPA は複数の DPA の配置のための Cisco Unified CallManager 「パイロット」Directory Number フィールドに入る値に頼ります。 CallManager 「パイロット」ディレクトリ番号は最初の DPA の最初のポートであるはずです。 最初の DPA が自身のポートと対応づけられたディレクトリ番号(DN)を知っている間、それに続く DPA はこの情報が正しい統合を確認することを必要とします。

      もっとも一般的な ミスコンフィギュレーションは顧客が CTI ルートポイントをか DPA に転送するハント グループを設定するときあります。 これは最初の DPA ポートに適切な DN を単に割り当てることができるように、必要ではないです。

Cisco DPA 7630/7610 で MWI を解決して下さい

正しくはたらく MWI のために同じ DN を使用するためにメッセージ待っている通知のために Cisco Unified CallManager および DPA は設定する必要があります。

/image/gif/paws/18779/smdi-6.gif

Service > Service Parameters > Cisco Unified CallManager の下で入る値、なぜなら MessageWaitingOn DN および MessageWaitingOffDN は設定します > CallManager DPA で入る値を一致する必要があります。

/image/gif/paws/18779/smdi-7.gif

  • 症状: MWI はオン/オフ回りません。

    • 提案: MWI オン/オフ DN がより多くの一般的 な パターンの一部ではないことを確認して下さい。 たとえばゲートウェイを指す 1xxx のルートパターンがないことを、確認して下さい。

  • 症状: MWI は Octel で 250/350 のプラットフォームを消しません。

    • 提案: 、メニュー 6.2 のメッセージ待っているタイムアウト機能は 1 に適切に機能する、MWI に関しては Octelシステムのインバンド 統合-タイムアウト = 確認応答設定設定 する必要があります。 2 つ-タイムアウト = 否定応答設定は Octelシステムをエラー 表示として確認トーンの欠如を解読するために指示します。 DPA 7630/7610 はことを 1 必要とします-タイムアウト = 確認応答 オプションは使用されます。

  • 症状: Cisco DPA 7630 によって、MWI はオン/オフ回りません。

    • 提案: Avaya G3 PBX は PBX で待っているメッセージを設定 するために機能コードを利用します。 従って Octel音声 メールシステムはそれらをまた使用します。 これらは従来 Leave Word Calling のための *4 および #4 アクティブになりますおよびキャンセル、それぞれです。 Octel で 250/350 のプラットフォームは、メニュー 6.2 の、インバンド 統合、そこに 2 つのパラメータです: MWI を無効にするために MWI をアクティブにするダイヤル シーケンスおよびダイヤル シーケンス。 これらの値は DPA で設定されるそれらが > Octel/Definity 統合設定すると同じであるはずです。

      smdi-8.gif

      1 つの原因または別のもののために、多くの Octelシステムにただ単に設定される MWI を無効にするために MWI をアクティブにするダイヤル シーケンスおよびダイヤル シーケンスが *4N および #4N よりもむしろ *4PN および #4PN で、あります。 P は 500 ms の一時停止を、通常表し、この遅延は DPA コード 1.2(1) の前に MWI においての問題を引き起こす場合があります。


関連情報


Document ID: 18779