このドキュメントでは、外部発信者が(コール キューイングを有効にできるようになった状態で、ハント パイロットにコールを発信した際に)Cisco Unified Communications Manager リリース 9.0(1) からの最初のアナウンスが聞こえない場合に、障害部分を特定する方法について説明します。
次の項目に関する知識が推奨されます。
このドキュメントは、特定のハードウェア バージョンに限定されるものではありません。 ソフトウェアについては、このドキュメントは、Cisco Unified Communications Manager リリース 9.0(1) 以上に当てはまります。
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。 稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
Cisco Unified Communications Manager リリース 9.0(1) では、ハント メンバーが電話に出られるようになるまで発信者をキューに入れることができるように、ユーザにコール キューイングが提供されています。 キューに入れられた発信者は、最初にグリーティング アナウンスを受信し、その後、保留中を示す音楽または音を受信します。
ハント パイロットに電話がかけられた際に、外部発信者に最初のアナウンスが聞こえなかった(ただし、ハント パイロットへの電話が内部の IP フォンからかけた場合は、最初のアナウンスは聞こえる)場合、これは通常、電話がつながる前にメディアをカットスルーしないサービス プロバイダーが原因で発生します。
この問題を裏づけるために、次のことを検証します。
該当のプロバイダーに送信しているプログレス インジケータの 8 を検証するには、ゲートウェイ上で isdn q931 のデバッグを有効にします。 ビジー状態のシステムがある場合、次のドキュメントで説明されている、デバッグ情報を収集するためのベスト プラクティスに従ってください: 「IOS ルータで適切かつ安全にデバッグ情報を収集する方法」。
表示されるプログレス インジケータは、次のとおりです。
*May 18 08:25:22.169: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x00BF Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98381 Exclusive, Channel 1 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x0180, '6611112' Plan:ISDN, Type:Unknown Called Party Number i = 0x81, '2000' Plan:ISDN, Type:Unknown *May 18 08:25:22.197: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x80BF Channel ID i = 0xA98381 Exclusive, Channel 1 *May 18 08:25:22.197: ISDN Se0/1/0:15 Q931: TX -> PROGRESS pd = 8 callref = 0x80BF Progress Ind i = 0x8188 - In-band info or appropriate now available ## Initial announcement being played ## *May 18 08:25:27.941: ISDN Se0/1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x80BF Progress Ind i = 0x8088 - In-band info or appropriate now available ## The call is ringing at agent phone ## *May 18 08:25:30.309: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x80BF ## The call is connected with the agent ## *May 18 08:25:30.313: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x00BF ## Call is ended by calling party ## *May 18 08:25:34.101: ISDN Se0/1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x00BF Cause i = 0x8290 - Normal call clearing *May 18 08:25:34.289: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x80BF *May 18 08:25:34.293: ISDN Se0/1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x00BF
上の例では、最初のアナウンスが約 5 秒間再生されていることがわかります。 次に、エージェントの電話で呼び出し音が鳴り(ALERTING)、エージェントが電話に出ると CONNECT メッセージが表示されています。
アナウンスをストリーミングしていることを検証するには、次のドキュメントで説明されているように、PCM キャプチャを取得します: 「Cisco IOS、電話、UCM および CUC パケットと PCM のキャプチャのコマンド リファレンス」。 pcm capture の収集で問題に直面している場合は、より時間の長いアナウンスの使用を検討してください。
両方の項目が正しく検証された場合、この問題は、電話がつながる前にメディア カットスルーを実行しないサービス プロバイダーが原因で発生しています。 この問題は、その該当のサービス プロバイダーが解決する必要があります。 上記の 2 つの項目のいずれかが確認できない場合は、Cisco Unified Communications Manager またはゲートウェイ側で、状況をさらに詳しく調査する必要があります。
Cisco Bug ID CSCuh15872 CUCM9 ネイティブのコール キューイングがアナウンス時に電話をつなぐ
Cisco Bug ID CSCug87543 CUCM ネイティブのコール キューイングが、入力が H323 Fast Start の場合に機能しない