- ホーム
- /
- 投稿記事
Control Hub で Webex Calling メディア品質をトラブルシューティングする
この記事の内容Webex Calling のトラブルシューティング ビューを使用すると、管理者は Webex 通話のメディア品質の問題をトラブルシューティングできます。 コールに関連する情報を検索したり、メディア統計を表示したり、問題が発生した場所を特定したり、問題を解決したりできます。
概要
考えられる原因を特定するには、トラブルシューティング ビューと Webex Calling Analytics ダッシュボード から得られた集約情報を使用することをお勧めします。 Webex Calling Analytics ダッシュボードを使用して、場所、ネットワークなどに関連する共通の原因を持つ複数のユーザーに影響を与える問題を表示します。Webex Calling トラブルシューティング ビューでは、個々の通話の問題を識別できます。
メディア品質のトラブルシューティング機能は、特定の設定を必要とせず、デフォルトで Control Hub で利用できます。 完全な顧客、読み取り専用、サポート、パートナー、およびパートナーの読み取り専用管理者が利用できます。
管理者は、少なくとも 1 つの Webex Calling 登録エンドポイントでメディアセッションが使用されたコールのリストを取得するために、次の条件を使用して検索できます。
メール ID
電話番号（文字列の完全一致）
MAC アドレス
通話 ID
メディア品質のトラブルシューティングにより、管理者は次のことを実行できます。
通話の参加者のエンドツーエンドのエクスペリエンスを表示します。
コールのホップの詳細を表示します。
メディアが Webex Calling クラウドを介して、またはユーザー間で直接トラバースするかどうかを表示します (Interactive Connectivity Establishment (ICE) を使用)。
通話にメディアがない場合、またはパスの最適化設定が失敗した場合、Insights を表示します。
過去 21 日間の通話を表示します。
ユーザーのエクスペリエンスに影響を与えた通話品質メトリクスを分析します。 たとえば、管理者は Wi-Fi ネットワーク経由でクライアントで高いジッタを監視できますが、パケット損失と遅延は許容される場合があります。
発信者または呼び出し元に問題があるかどうかを検出します。
メディア品質のトラブルシューティングはメディア セッションにのみ適用され、コール シグナリング セッションは表示されません。 たとえば、Alex は CFA (Call Forward All) をセットアップした Bob を Christina に呼び出し、Christina はそのコールに応答しました。 このシナリオでは、メディア トラブルシューティング ビューは、シグナリング フローやコール ライフサイクルではなく、メディア エクスペリエンスのトラブルシューティングに焦点を当てているため、コールが Alex と Christina の間で発生したことを示します。
Webex Calling を使用した通話は、通話の終了後に表示されます。
トラブルシューティング ビューは、関連するすべてのメトリクスを提供して問題領域を特定するのに役立ち、必ずしも通話不良の根本原因を提供することはできません。 これらのポインタを見て、さまざまな要因を特定し、解像度のオプションを決定します。
ユーザーのエンドツーエンドのエクスペリエンス。
ホップの詳細ビュー。
ユーザーまたはメディア リレー ポイントからメトリクスを送受信します。
コールが外部ネットワークに、または外部ネットワークから、または Webex Calling 登録済みエンドポイント間で発生したかどうか。
サポートされる通話フロー
メディア品質レポートは、発信者と発信者のエンドポイントとメディアリレーポイントから収集されます。 これにより、メディアエクスペリエンスのセグメンテーションが絞り込まれ、次の場所で問題が発生したかどうかを特定できます。
発信者または呼び出し元
Webex Calling クラウドへの、またはクラウドからのメディア パス。
コールに少なくとも 1 つの Webex Calling 登録済みエンドポイントで確立されたメディア セッションがある場合、コール レッグが表示されます。 たとえば、ハント グループから 8 人のエージェントへの発信コールで、1 人のエージェントだけが応答する場合、他の 7 人のエージェントに対してトラブルシューティングを行うメディア エクスペリエンスはありません。
Webex Calling のトラブルシューティングには、次の 5 種類のメディア エクスペリエンスまたはパスがあります。
オンネット最適化 - ICE が成功し、メディアがユーザー間で直接流れる組織内のコール。 詳細については、Webex Calling Media Optimization with Interactive Connectivity Establishment (ICE)を参照してください。
On-net Unoptimized - Interactive Connectivity Establishment（ICE）が不可能または確立された組織内のコール。 このシナリオでは、メディアは Webex Calling クラウドを通じて流れます。
オンネット クラウド ホステッド - クラウドでホストされているメディア サーバーによってメディアが提供されている組織内の通話（ボイスメールのリスニング、自動アテンダントへのダイヤルなど）。
Webex Calling 登録済みエンドポイントへのオフネット通話 -
Cloud Connected PSTN Provider 経由で- 相手が PSTN ネットワーク上にある組織の着信および発信コール。 メディアは、高品質の相互接続を介して、クラウド接続された PSTN プロバイダー (CCPP) を介して中継されます。
ローカル ゲートウェイ経由 - 相手方のメディアが企業を経由している組織の着信および発信コール。 ローカル ゲートウェイの背後に、メディア セッションは、エンタープライズがホストするユーザ（たとえば、エンタープライズのコール制御に登録されている）から、または PSTN から行うことができます。ここで、PSTN はエンタープライズから提供されます。
ポイントツーポイントオンネット通話に関与する Webex Calling 登録ユーザーが 1 人または 2 人いる場合、トラブルシューティング ビューには、1 人または両方の当事者のメトリクスが表示されます。 コールがオフネット（ユーザ 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 セッションでの通話の場合、このグレーディングは適用されません。 通話エクスペリエンスは次のように評価されます。
|
| 4 | リスティングビューで特定のコールをクリックして、ホップの詳細を確認します。 [ホップの詳細（Hop Detail）] ビューが表示されます。
ホップの詳細から、次のことができます。
エンドツーエンドの通話エクスペリエンスは、通話の最後に各 Webex Calling 登録エンドポイント (Webex アプリまたは 8865 または Desk Pro などのデバイス) から収集されたメディア品質データに基づいています。 これらのしきい値を満たす場合、コールは良好と評価されます。
ホップの品質は、Webex Calling クラウドのメディア リレー ポイントから収集されたデータから得られます。 CCPP またはローカル ゲートウェイを介した PSTN 通話の場合、データ収集は Webex Calling クラウドからであり、PSTN エンドポイントからではありません。 ホップは、これらのしきい値を満たす場合、良いものとして評価されます。
ホップメトリクスは、セッション中にサンプリング時間とネットワークの変動に応じて異なります。 メディア リレー ポイントとクライアント (エンド ツー エンド エクスペリエンス) によってレポートされる値は、一致しない場合があります。 ただし、パスに沿ってセグメンテーションを許可するために、それらは密接に整列している必要があります。 Analyticsから得られた集約情報を使用して、個々の通話のトラブルシューティング ビューを使用することをお勧めします。 トラブルシューティング ビューを使用して、さまざまなコール タイプの通話品質を分析しましょう。 |
ICE が成功し、クラウド内のメディア リレーがパスから削除される組織内のコール。 メディアフローは、ユーザーのデバイス間で直接行われます。
推論:
| 1 | 通話は、発信者と発信者の両方でエンドツーエンドのエクスペリエンスが優れているのと同じくらい良い成績で評価されます。 |
| 2 | 管理者は、メディアが 2 人のユーザー間で直接流れ、Webex Calling クラウドを経由しないことを確認できます。 最適化されたコール フローは、エンタープライズまたはローカル ネットワークが問題の原因である場合、2 人のユーザー間のメディアがローカル ネットワークを横断するため、エクスペリエンスが低下する可能性があります。 レイテンシーまたは RTT は、最適化されたコールでは常に低くなりますが、パケット損失とジッタは、2 人のユーザ間のネットワークに応じて要因となる可能性があります。 |
推論:
管理者は以下を観察できます。
| 1 | 発信者のエンドツーエンドのエクスペリエンスは貧弱と評価されます。 |
| 2 | 発信者のネットワーク ホップには、送信ストリームと受信ストリームの両方に影響する問題があります。 |
| 3 | 呼び出し元のネットワーク ホップに問題はありません。 |
| 4 | 発信者の問題により、発信者のエンドツーエンドのエクスペリエンスは貧弱と評価されます。 |
推論:
コールは、発信者のエンドツーエンドのエクスペリエンスが受け入れられているしきい値の範囲内であるのと同じ程度に評価されます。 管理者は次のことを観察できます。
| 1 | 発信者のネットワーク ホップは、一部のメトリクスが許容可能なしきい値を超えているため、貧弱に評価されます。 |
| 2 | ボイスメールからの送信ストリームは、メディア リレー ポイントから収集されたメトリックに従って良好と評価されます。 |
| 3 | ボイスメールの収集または入金に使用されるメディア サーバーは、現在メトリクスをレポートしていません。 ただし、これらのサーバーは Webex Calling Cloud の一部としてホストおよび管理されるため、そのリンクセグメントの品質は内部的で、常に高品質で低遅延です。 |
| 4 | 管理者は、発信者のエンドツーエンドのエクスペリエンスが良いと評価されるのを、ホップは悪いと評価されるのを、観察できます。 これは、呼び出し元のホップが、発信者のネットワークのパフォーマンスの低下を補う良好なネットワークを持っているためです。 |
この例では、クライアント メディアはクラウド経由で PSTN プロバイダーから送信されます。
コールは、発信者のエンドツーエンドのエクスペリエンスが受け入れられているしきい値の範囲内にないため、低評価になります。 管理者は以下を観察できます。
| 1 | 問題は、発信者の PSTN ホップ、特に送信ストリームにあります。 |
| 2 | 呼び出し元のネットワーク ホップに問題はありません。 |
| 3 | 発信者の問題により、発信者のエンドツーエンドのエクスペリエンスは貧弱と評価されます。 |
| 4 | PSTN ネットワーク上の発信者のエンドツーエンドのエクスペリエンスと受信ストリームのメトリックは、これらのメトリックが Webex Calling Cloud に送信されないため、現在利用できません。 |
発信者のメディアが企業から発信される組織内外への通話。 メディアセッションは、エンタープライズホストユーザー（UCM に登録されているなど）から、または PSTN から行うことができます。PSTN はエンタープライズを通じて提供されます。
推論
コールは、発信者のエンドツーエンドのエクスペリエンスが受け入れられているしきい値の範囲内にないため、評価が低くなります。 管理者は以下を観察できます。
| 1 | 送信ストリームと受信ストリームの両方で Webex Calling Cloud への発信者のホップに問題があります。 |
| 2 | 発信者のエンドツーエンドのエクスペリエンスは、ホップで観察された問題またはユーザーのエンドの問題（デバイス、ネットワークなど）により、貧弱と評価されます。 |
| 3 | 呼び出し先の端から Webex Calling Cloud への着信トラフィックは良好と評価されます。 |
| 4 | これらのメトリックは Webex Calling Cloud に送信されないため、ローカル ゲートウェイからコールされた発信者のエンドツーエンドのエクスペリエンスと受信ストリーム メトリックは現在利用できません。 |
メディア品質の問題のトラブルシューティング
hop-by-hopビューは、問題が発生した場所を見つけるのに役立ちます。 問題がどこにあるかを確認し、メトリック（ジッター、パケット損失、遅延）を使用して、問題をトラブルシューティングするために以下を試すことができます。
メディア問題の典型的な可能性は次のとおりです。
ネットワーク/ISP/ロケーション固有の問題 - ファイアウォール、ネットワーク構成、または帯域幅により、特定のロケーションまたはネットワーク サブネットでのエクスペリエンスが低下するパターンがあります。 分析ビューを使用して、通話ごとのトラブルシューティング ビュー（貧弱なセッションに関連付けられているロケーションを識別する）を使用して、ロケーションの集約パターンを確認します。
ユーザー固有の問題 - ユーザーまたはデバイスは、ネットワークの不良（Wi-Fiや在宅勤務など）で接続されているため、関連するネットワーク機能によってエクスペリエンスが影響を受けます。 ネットワークに関する問題を特定するには、「CScan を使用して Webex Calling ネットワーク品質をテストする」の記事を参照してください。
通話タイプ固有の問題 - ユーザーのエクスペリエンスが低いのは、エンドポイントの品質が原因です。 これは、ユーザがモバイルネットワーク上の別のユーザと話していて、セッションが PSTN ネットワーク上のパケット損失が大きいという PSTN シナリオで典型的です。
No-media issue- 一部のホップでメディア送信がない場合があります。 [インサイト] バナーには、[ホップの詳細] ページの上部に原因が表示され、ホップの詳細ページの情報ボックスに責任者が表示されます。 通話中にメディアが存在しない原因と、責任のある当事者はここに記載されています。
Webex は送信者からメディアを受信しません。
Webex は受信者からメディアを受信しません。
Webex はどちらの方向からもメディアを受信しません。
Webex は受信者にメディアを送信しません。 Webex エンジニアリングはこの問題に対処します。
Webex はクラウド PSTN からメディアを受信していません。 Webex エンジニアリングはこの問題に対処します。
Webex はクラウド サービスからメディアを受信していません。 Webex エンジニアリングはこの問題に対処します。
Webex はローカル ゲートウェイからメディアを受信していません。 顧客管理者は問題を調査する必要があります。
メディア パスの最適化の失敗- メディア パスの最適化を正常に設定できないコールがいくつかあります。 [インサイト（Insights）] バナーには、ICE コールが失敗した原因と [ホップの詳細（Hop details）] ページの上部に解像度が表示されます。
考えられる理由の一部は
サーバーアクセスが停止したため、ICE が失敗しました - Webex Calling ポート参照情報を参照してください
接続チェックのため ICE が失敗しました - ネットワーク間の接続を確認します
デフォルトのパス往復時間が最適化されたパスに類似/優れていたため、ICEが失敗しました
トラブルシューティング ビューの凡例
ホップ バイ ホップ ビューの右側のペインで、次の通話の詳細を参照してください。
| 期限 | 説明 |
| 通話日付 | 通話が発生した日付。 |
| 通話時刻 | 通話の開始および終了時刻を検索ビューで選択したタイムゾーンで表示します。 |
| セッションタイプ | サポートされているセッションのタイプ。 例: Webex Call |
| 参加者 | 通話に参加した参加者の数。 |
| 発信者名 | 発信者の名前。 |
| 発信者メール アドレス | 発信者のメールアドレス。 |
| 発信者番号 | 発信者が通話中に使用した電話番号。 |
| 音声 | 使用された音声タイプです。 |
| ビデオ | 参加者がビデオを有効にしている場合は [はい] と表示されます。 ビデオがまったく有効になっていない場合は、[いいえ（No）] が表示されます。 |
| パスの最適化 | コール パスの最適化がコールに適用されるかどうかを指定します。 受け入れられる値は次のとおりです。 ICE（Interactive Connectivity Establish） PNC (Private Network Connect) です。 最適化なし |
| 通話タイプ | 通話タイプは、次のいずれかになります。 緊急 エンタープライズ 国際通話 モバイル 国内 操作係 Premium ショートコード 無料通話 不明 URI |
hop-by-hop ビューでこれらの通話メトリックを表示します。
| 期限 | 説明 |
| エンドポイント | 次のいずれかを表示します。
|
| ハードウェア | 次のいずれかを表示します。
|
| 場所 | ユーザーに設定されている Webex Calling ロケーション。 |
| 市内 IP | メディアを送信するために使用しているネットワーク インターフェイスのクライアントのローカル IP アドレス。 ユーザーのパーソナル アイデンティティを保護するために IP アドレスを一部非表示にしています。 |
| パブリック IP | これは、クラウドによって表示されるクライアントのパブリック IP アドレスです。 企業にとって、これはNATを提供するファイアウォールのアドレスです。 ユーザーのパーソナル アイデンティティを保護するために IP アドレスを一部非表示にしています。 |
| MAC アドレス | クライアント エンドポイントの MAC アドレス。 |
| 地理位置情報 | パブリック IP アドレスの Geo ルックアップ。 PNC 経由で接続されている場合、このアドレスは正確ではありません。 ユーザーが Webex アプリを使用し、VPN 経由で企業に接続している場合、ロケーションは正確ではありません。 |
| ISPサービス | Webex Calling Cloud へのネットワーク接続を提供するインターネット サービス プロバイダー。 |
| ネットワーク | クライアントがメディアを交換するために使用したネットワーク接続のタイプです。 可能な値:
|
| 音声コーデック | (送信または受信) クライアントによって送信されるメディアに使用するメディアエンコーディングおよびデコードフォーマット。 |
| ビデオコーデック | (送信または受信) クライアントによって送信されるメディアに使用するメディアエンコーディングおよびデコードフォーマット。 ビデオ通話にのみ適用されます。 |
| コール ID | コール レッグを識別するために使用される内部識別子。 |
一部のメトリックは、ユーザーのアイデンティティを保持するために記事のスクリーンショットでマスクされます。
制限事項
メディア品質メトリクスは、次のデバイスからは利用できません。
アナログ電話
サードパーティ製デバイス
IPv6 エンドポイント
