概要

考えられる原因を特定するために、トラブルシューティング ビューを使用するとともに、 Webex Calling Analyticsダッシュボードを選択します。 Webex Callingアナリティクスダッシュボードを使用して、ロケーション、ネットワークなどに関連する共通の原因で複数のユーザーに影響を与える問題を確認します。 Webex Callingのトラブルシューティング ビューでは、個々の通話の問題を識別できます。

メディア品質のトラブルシューティング機能には特定の構成が必要なく、Control Hub のデフォルトで使用できます。 フル顧客、読み取り専用、サポート、パートナー、およびパートナー読み取り専用管理者が利用できます。

管理者は、次の条件を使用して検索を行い、メディア セッションが少なくとも 1 つ使用された通話のリストを取得できます。 Webex Calling登録済みエンドポイント:

  • メール ID

  • 電話番号 (完全一致文字列)

  • MAC アドレス

  • 通話 ID

メディア品質のトラブルシューティングにより、管理者は次のことができます。

  • コールの参加者のエンドツーエンドのエクスペリエンスを表示します。

  • コールのホップ詳細を表示します。

  • メディアがWebex Callingクラウドを通じて、またはユーザー間で直接(Interactive Connectivity Establishment(ICE)を使用)トラバースするかどうかを表示します。

  • 通話にメディアがない場合、またはパス最適化の設定が失敗した場合、インサイトを表示します。

  • 過去 21 日間の通話を表示します。

  • ユーザのエクスペリエンスに影響を与えた通話品質のメトリックを分析します。 たとえば、管理者はWi-Fiネットワーク経由でクライアントの高いジッターを観察するかもしれませんが、パケット損失と遅延は許容できます。

  • 問題が発信者側にあるのか、呼び出し先にあるのかを検出します。


メディア品質のトラブルシューティングは、メディア セッションにのみ適用され、コール シグナリング セッションは表示されません。 たとえば、Aex は CFA (不在転送) を設定した Bob を Event Center に発信し、Christina はその通話に応答します。 このシナリオでは、メディア トラブルシューティング ビューには、Aex とChristina 間で通話が発生したことが示されています。

使用するコールはWebex Callingコールが終了した後に表示されます。

トラブルシューティング ビューは、すべての関連メトリックスを提供することによって問題領域を特定するのに役立ちますが、必ずしも品質の低いコールの根本原因を提供することはできません。 以下のポインタを参照して、さまざまな要素を識別し、解決オプションを決定してください。

  • ユーザーのエンドツーエンドのエクスペリエンス。

  • [ホップの詳細(Hop Details)] ビュー。

  • ユーザまたはメディアリレーポイントからメトリックを送信または受信します。

  • コールが外部ネットワークとの間で行われたか、外部ネットワークから行われたか、あるいはWebex Calling登録済みエンドポイント。

サポートされるコール フロー

メディア品質レポートは、発信者と着信者のエンドポイント、およびメディアリレーポイントから収集されます。 これにより、メディア エクスペリエンスをセグメンテーションで絞り込み、問題が発生する場所を特定できます。

  • 発信者または呼び出し先

  • へのメディア パスWebex Callingクラウド。


少なくとも 1 つのメディア セッションが確立されている場合にコール レッグが表示されます。 Webex Callingコールの登録済みエンドポイント。 たとえば、ハント グループから 8 人のエージェントへの発信コールでは、1 人のエージェントだけが応答する場合、他の 7 人のエージェントに対してトラブルシューティングするメディア エクスペリエンスがありません。

メディア エクスペリエンスまたはパスには 5 つのタイプがあります。 Webex Callingトラブルシューティング。これは次のとおりです。

  • オンネットが最適化済み- ICE が成功し、ユーザー間でメディアが直接流れる組織内での通話。 参照先Interactive Connectivity Establishment (ICE) を使用したWebex Calling のメディア最適化をご覧ください。

  • オンネット 最適化前– Interactive Connectivity Establishment(ICE)が不可能、または確立されなかった組織内のコール。 このシナリオでは、メディアはWebex Calling クラウドを通過します。

  • オンネット クラウド ホスト- クラウドでホストされているメディア サーバーによってメディアが提供される組織内での通話 (ボイスメールを聞いている、自動アテンダントにダイヤルしたりするなど)。

  • Webex Calling登録済みエンドポイントとのオフネット コール-

    • Cloud Connected PSTN プロバイダー経由- 相手側が PSTN ネットワーク上にある組織への着信通話と発信通話。 メディアは、高品質の相互接続を通じて、クラウド接続の PSTN プロバイダー (CCPP) を通じて中継されます。

    • ローカル ゲートウェイ経由- 相手側のメディアが企業を経由している組織への着信と発信の通話。 ローカル ゲートウェイの背後でのメディア セッションは、エンタープライズがホストしたユーザー (たとえば、エンタープライズの通話制御に登録されている) または PSTN からのもので、PSTN はエンタープライズによって提供されます。


1 つか 2 つのWebex Callingポイントツーポイント オンネット コールに関係している登録ユーザの場合、トラブルシューティング ビューでは、一方または両方のメトリックが表示されます。 コールがオフネットの場合 (ユーザ 1 が PSTN ユーザーからコールを受信する)、トラブルシューティング ビューには、メディア リレー ポイントから取得されたメトリックとともに、User1 のクライアント メトリックのみが表示されます。

トラブルシューティング ビューのコール シナリオのほとんどは、2 つのコール レッグ(発信者と着信側)を表示します。ただし、一部のコール シナリオ (コールパークや取得など) では、1 つのコール レッグしか表示されません。 このような場合、トラブルシューティング ビューには他のコール レッグが個別に表示されます。 これは、コールのトラブルシューティングと問題が発生した場所の検出を妨げません。 ただし、管理者は、重複時間など共通のエンティティを使用して、2 つのコールレッグを手動で関連付ける必要があります。 トラブルシューティング ビューへの今後の機能強化で、手動でのルックアップを使用する必要がなくなります。

次に、 Webex Callingトラブルシューティングの表示

Webexコールを分析するには、次の手順を実行します。

1

顧客ビューからhttps://admin.webex.com/監視中次のリンクをクリックしてください:トラブルシューティングを選択します。

2

選択ミーティングと通話ユーザーまたはデバイスのメールID 、電話番号 (完全文字列一致)、ユーザーまたはデバイスのMACアドレス、表示するコール レッグのコール ID を検索します。

検索に関連付けられているすべての通話とミーティングの情報を表示します。


 

リストビューには、少なくとも 1 つのWebex Calling登録済みエンドポイントとメディア セッション。

3

このWebex Callingコールの品質は評価されます。 ただし、 WebexミーティングまたはWebexセッションで通話、この評価は適用されません。 通話エクスペリエンスは、次のように分類されています。

  • 悪い– は、発信者または呼び出し先のいずれかのエンドツーエンドのエクスペリエンスが不十分であることを示します (たとえば、音声が途切れることがあります)。
  • 良好-発信者と呼び出し先のエンドツーエンドのエクスペリエンスがしきい値を超えなかったことを示します。
  • なし- ミーティングまたはWebexセッションでの通話に適用されます。
  • 利用不可- ミーティングまたはWebexセッションでの通話に適用されます。
4

リスト ビューの特定のコールをクリックして、ホップの詳細を調べます。 次のようにホップの詳細ビューが表示されます。

ホップの詳細から、次のことができます。

  • 以下のシナリオのいずれかまたは両方で、コールインサイトを表示します。

    • 通話に関連するホップにメディアがありませんでした

    • パス最適化の設定に失敗しました。

  • デバイスの上にカーソルを合わせて、エンドツーエンドの通話エクスペリエンスを表示します。

  • エンドポイント 間のホップにカーソルを合わせますWebex Callingクラウドに移動してホップの詳細を表示します。

エンドツーエンドの通話エクスペリエンスは 各サイトから収集されたメディア品質データに基づいていますWebex Calling登録済みエンドポイント (Webexアプリまたは 8865 などのデバイス) を通話の最後に表示します。 通話は、次のしきい値を満たしている場合、良好と評価されます。
  • パケット損失 5% 以下

  • 遅延または往復時間(RTT)400 ms 未満

  • 150 ms 未満のジッター

ホップの品質は、 Webex Callingクラウド。 CCPP またはローカル ゲートウェイ経由の PSTN コールの場合、データはWebex Callingクラウドに送信し、PSTN エンドポイントから送信しないでください。 これらのしきい値を満たすホップは、良好と評価されます。

  • パケット損失が 2.5% 未満。

  • 遅延または RTT が 200 ms 未満

  • ジッターは 75 ミリ秒未満。


 

ホップ メトリックは、サンプリング時間とネットワークの変動性に応じて、セッション中に変わります。 メディアリレーポイントとクライアント (エンドツーエンドのエクスペリエンス) によって報告された値は一致しない場合があります。 ただし、パスに沿ったセグメンテーションを可能にするために、厳密に一致している必要があります。

個別の通話のトラブルシューティング ビューを使用して、分析を選択します。

トラブルシューティング ビューを使用して、さまざまな通話タイプの通話品質を分析しましょう。

ICE が成功し、クラウド内のメディアがリレーされた組織内の通話は、パスから削除されます。 メディア フローは、ユーザーのデバイス間で直接行われます。

推論

1

発信者と発信者の両方がエンドツーエンドのエクスペリエンスが良好である限り、通話は良好として評価されます。

2

管理者は、メディアが 2 人のユーザー間を直接流れ、 Webex Calling クラウドを経由しないことを確認できます。


 

最適化された通話フローは、エンタープライズまたはローカルのネットワークが問題の原因である場合、2 人のユーザ間のメディアがローカルのネットワークを通過するため、体験が低下することがあります。 遅延または RTT は最適化された通話では常により低いですが、パケット損失とジッタはまだ 2 人のユーザ間のネットワークに応じた要因となります。

ICE コールが成功せず、メディアがWebex Callingクラウドに流れる組織内のコール。

推論

管理者は次のことを確認できます。

1

発信者のエンドツーエンドのエクスペリエンスは、不良と評価されます。

2

送信ストリームと受信ストリームの両方に影響する発信者のネットワーク ホップに問題があります。

3

呼び出し先のネットワーク ホップには問題がありません。

4

呼び出し先の問題のため、呼び出し先のエンドツーエンドのエクスペリエンスは悪いと評価されます。

クラウドでホストされているメディア サーバーによってメディアが提供される組織内での通話。

推論

通話は、発信者のエンドツーエンドのエクスペリエンスが受け入れられたしきい値内にあると評価されます。 管理者は、次の点を確認できます。

1

発信者のネットワーク ホップは、一部のメトリックが許容可能なしきい値を超えていると評価されます。

2

ボイスメールからの送信ストリームは、メディアリレーポイントから収集されたメトリックに従って良いと評価されます。

3

ボイスメールの収集または保管に使用されるメディア サーバは、現在、メトリックをレポートしません。 ただし、これらのサーバーはWebex Callingクラウドの一部としてホストおよび管理されるため、そのリンクセグメントの品質は内部で常に高品質で低遅延です。

4

管理者は、ホップが低品質と評価されている場合でも、発信者のエンドツーエンドのエクスペリエンスが良好と評価されているのを確認できます。 これは、発信者のネットワークのパフォーマンス低下を補正することで、着信側のホップのネットワークが良好になるためです。

相手が PSTN ネットワーク上にある組織との間で通話する。 メディアは、クラウド接続の PSTN プロバイダー (CCPP) からリレーされます。

この例では、クライアント メディアはクラウドを通して PSTN プロバイダーから着信しています。

呼び出し先のエンドツーエンド エクスペリエンスが受け入れられたしきい値内にないため、通話は不良と評価されます。 管理者は次のことを確認できます。

1

問題は、特に発信者の PSTN ホップにあり、送信ストリームにあります。

2

呼び出し先のネットワーク ホップには問題がありません。

3

呼び出し先の問題のため、呼び出し先のエンドツーエンドのエクスペリエンスは悪いと評価されます。

4

PSTN ネットワーク上の発信者のエンドツーエンドのエクスペリエンスおよび受信ストリーム メトリックは、これらのメトリックはWebex Callingクラウドに送信されないため現在利用できません。

発信者のメディアが企業からのものである組織との間で通話する。 メディア セッションは、エンタープライズがホストするユーザー (たとえば、UCM に登録) から、または PSTN がエンタープライズを通じて提供される場合、PSTN からのものでした。

推論

発信者のエンドツーエンドのエクスペリエンスが受け入れられたしきい値内にないため、通話は不良と評価されます。 管理者は次のことを確認できます。

1

送信と受信の両方のストリームで、 Webex Callingクラウドへの発信者のホップに問題があります。

2

発信者のエンドツーエンドのエクスペリエンスは、ホップで見られた問題またはユーザー側の問題 (デバイス、ネットワークなど) のせいで、不良と評価されます。

3

着信側からWebex Callingクラウドへの着信トラフィックは、良好と評価されます。

4

エンドツーエンドのエクスペリエンスとローカル ゲートウェイから呼び出される発信者の受信ストリーム メトリックは、これらのメトリックがWebex Callingクラウドに送信されないため現在利用できません。

メディア品質の問題をトラブルシューティングする

ホップごとのビューは、問題が発生した場所を特定するのに役立ちます。 これで、問題の場所が特定できたので、メトリクス (ジッタ、パケット損失、遅延) を使用して以下を試して問題のトラブルシューティングを行います。

メディアの問題の一般的な可能性:

  • ネットワーク/ISP/場所特有の問題- ファイアウォール、ネットワーク構成、または帯域幅が原因で、特定の場所またはネットワーク サブネットで低品質のエクスペリエンスのパターンが存在します。 コールごとのトラブルシューティング ビュー (低品質のセッションに関連付けられているロケーションの特定) と分析ビューを組み合わせて、ロケーションの集約パターンを確認します。

  • ユーザー特有の問題- ユーザーまたはデバイスが脆弱なネットワーク (たとえば、 Wi-Fiや自宅から仕事をしているなど) に接続されているため、そのユーザーのエクスペリエンスは、関連するネットワーク機能に影響を受けます。 参照先: CScan を使用してWebex Callingネットワークの品質をテストするネットワークに関する問題を特定します。

  • コール タイプ固有の問題- 通話品質の低下は、遠端の品質に起因します。 これは、ユーザーがモバイル ネットワーク上で別のユーザーと通話しており、PSTN ネットワーク上でセッションのパケット損失が高い PSTN のシナリオで一般的です。

  • メディアなしの問題- 一部のホップでメディアが送信されない場合があります。 この Insights バナーには、[ホップの詳細] ページの上部に原因が表示され、責任者は [ホップの詳細] ページの情報ボックスに表示されます。 通話でメディアが見つからない場合に考えられる原因の一部と、責任当事者について、以下に示します。

    • Webexが送信者からメディアを受け取っていません。

    • Webexがレシーバーからメディアを受信していません。

    • Webexは両方向からのメディアを受信していない。

    • Webexが受信者にメディアを送信しません。 Webex のエンジニアリングはこの問題に取り組んでいます。

    • Webexが Cloud PSTN からメディアを受信していません。 Webex のエンジニアリングはこの問題に取り組んでいます。

    • Webexはクラウド サービスからメディアを受信していません。 Webex のエンジニアリングはこの問題に取り組んでいます。

    • Webexがローカル ゲートウェイからメディアを受信していません。 顧客管理者はこの問題を調査する必要があります。

  • メディア パスの最適化に失敗しました- 一部のコールはメディア パスの最適化を正常にセットアップできません。 Insights バナーは、ICE 通話が失敗した原因と、ホップ詳細ページの上部にある解決方法を表示します。

    考えられるいくつかの理由を次に示します:

    • サーバー アクセスが妨げられたため ICE が失敗しました - 「 Webex Callingポート参照情報」を参照してください

    • 接続チェックのために ICE が失敗しました - ネットワーク間の接続を確認してください

    • デフォルト パス ラウンドトリップ時間が、最適化されたパスと同様/優れていたため、ICE が失敗しました。

トラブルシューティング ビューの凡例

ホップバイホップ ビューの右側のペインに、次の [通話の詳細] が表示されます。

期限 説明
通話日付 コールが発生した日付。
通話時刻 通話の開始および終了時刻を検索ビューで選択したタイムゾーンで表示します。
セッションタイプ

サポートされているセッションタイプです。 例: Webex Call

参加者 通話に参加した参加者の数。
発信者名 発信者の名前。
発信者メール アドレス 発信者のメール アドレス。
発信者番号 発信者が通話中に使用した電話番号。
音声 使用された音声タイプです。
ビデオ 参加者がビデオを有効にしている場合は、[はい] と表示されます。 ビデオが全く有効になっていない場合、「いいえ」と表示されます。
パスの最適化

コール パスの最適化をコールに適用するかどうかを指定します。 有効な値は以下のとおりです。

ICE(Interactive Connectivity Establish)

PNC (プライベート ネットワーク接続)。

最適化なし

通話タイプ

[通話タイプ(Calling Type)] は、次のいずれかになります。

緊急

エンタープライズ

国際通話

モバイル

国内

操作係

Premium

ショートコード

無料通話

不明

URI

次のとおりホップバイホップ ビューでこれらのコール メトリックを表示します。

期限 説明
エンドポイント

次のいずれかが表示されます。

  • 物理エンドポイントの卓上電話。

  • Webex アプリ

ハードウェア

次のいずれかが表示されます。

  • 物理エンドポイントの卓上電話モデル情報。

  • Webexアプリの場合は「-」

場所

ユーザーに対して設定されたWebex Callingのロケーション。

市内 IP

メディアの送信に使用されるネットワーク インターフェイスのクライアントのローカルIPアドレス。

パブリック IP

これは、クラウドから見えるクライアントのパブリック IPアドレスです。 エンタープライズの場合、これは NAT を提供するファイアウォールのアドレスになります。

MACアドレス

クライアント エンドポイントのMACアドレス。

地理情報

パブリック IP アドレスの Geo ルックアップ。 PNC で接続されている場合、このアドレスは正確ではありません。 ユーザーがWebexアプリを使用し、 VPNを通してエンタープライズに接続している場合、ロケーションは正確ではありません。

ISP

Webex Callingクラウドにネットワーク接続を提供するインターネット サービス プロバイダ。

ネットワーク

クライアントがメディアを交換するために使用したネットワーク接続のタイプです。 取り得る値は次のとおりです。

  • Wi-Fi

  • イーサネット

  • 携帯

  • 不明

音声コーデック

(送信または受信)クライアントによって送信されたメディアのために使用されているメディアのエンコーディングおよびデコーディングの形式。

ビデオコーデック

(送信または受信)クライアントによって送信されたメディアのために使用されているメディアのエンコーディングおよびデコーディングの形式。 ビデオ通話にのみ適用されます。

コール ID

コール レッグを識別するために使用される内部識別子。


一部のメトリックスは、ユーザーの ID を保持するために、記事のスクリーンショットでマスクされています。

制限事項

メディア品質メトリックスは、次のデバイスからは使用できません。

  • アナログ電話機

  • サードパーティ デバイス

  • IPv6 エンドポイント