この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Ciscoゲートウェイに関連するIPテレフォニーの片通話で発生する可能性のある一般的な問題について説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
このドキュメントは、次のような問題に対応し、そのシナリオとソリューションを提供しています。
IPステーションからCisco IOS音声ゲートウェイまたはルータを経由して電話コールが確立されると、通話者の一方のみが音声を受信します(単方向通信)。
2 つのシスコのゲートウェイ間でトール バイパス コールが確立されると、通話者のうち 1 人だけが音声を受信します(単方向通信)。
VPN 3002 ハードウェア クライアントの背後にある IP ステーションからの通話が確立されると、通話者のうち 1 人だけが音声を受信します(単方向通信)。
IP テレフォニーの片通話の原因はさまざまですが、根本的な問題は通常、IP ルーティングの問題に関係します。このセクションでは、この領域で既知のシナリオとソリューションをいくつか取り上げます。
VG200 など、一部の Cisco IOS ゲートウェイは、デフォルトで IP ルーティングがディセーブルになっています。このデフォルト設定により、単方向音声の問題が生じます。
注:続行する前に、ルータでIPルーティングが有効になっていることを確認してください。つまり、ルータで no ip routing グローバル コンフィギュレーション コマンドが使用されていないことを確認します。
IP ルーティングをイネーブルにするには、Cisco IOS ゲートウェイ上でこのグローバル コンフィギュレーション コマンドを発行します。
voice-ios-gwy(config)#ip routing
最初に必ず、基本的な IP 到達可能性を確認します。Real-Time Transport Protocol(RTP)ストリームはコネクションレス型(UDP経由で転送される)であるため、一方向のトラフィックは正常に転送されますが、反対方向のトラフィックは失われます。次の図に、これが発生するシナリオを示します。
サブネット A とサブネット B はどちらもサブネット X に到達可能です。サブネット X はサブネット A とサブネット B に到達可能です。このため、端末(A および B)と Cisco CallManager との間で TCP 接続を確立できます。したがって、シグナリングは問題なく両方の端末に到達でき、A と B 間のコールを確立できます。
コールが確立されたら、音声を伝送する RTP ストリームは、端末間を両方向に流れる必要があります。サブネット B はサブネット A に到達可能ですが、サブネット A はサブネット B に到達できない場合があります。このため、A から B への音声ストリームがいつも失われます。
これは、基本的なルーティングの問題です。ゲートウェイ B から電話機 A への ping を正常に実行できる状態にするには、IP ルーティングのトラブルシューティング方法を使用します。ping は双方向の IP 到達性の検証手段であることを覚えておいてください。
このドキュメントでは、IP ルーティングのトラブルシューティングについては説明していません。ただし、次の手順を実行する必要があります。
デフォルト ゲートウェイを端末で設定している。
このデフォルト ゲートウェイ上の IP ルートが宛先ネットワークに到達している。
このリストでは、各種 Cisco IP Phone 上でデフォルト ルータまたはゲートウェイの設定を確認する方法について説明します。
Cisco IP Phone 7910:[Settings] を押してオプション 6 を選択し、[Default Router] フィールドが表示されるまで [volume down] を押します。
Cisco IP Phone 7960/40:[Settings] を押してオプション 3 を選択し、[Default Router] フィールドが表示されるまで下にスクロールします。
Cisco IP Phone 2sp+/30vip:**# を押して、gtwy= が表示されるまで # を押します。
注:Cisco IP SoftPhoneアプリケーションを使用し、ボックスに複数のネットワークインターフェイスカード(NIC)が取り付けられている場合は、ボックスが正しいNICを調達していることを確認してください。この問題は、IP SoftPhone ソフトウェア バージョン 1.1.x に共通して存在します。この問題は、バージョン1.2で解決する必要があります。
注:Cisco DT-24+ゲートウェイを使用する場合は、DHCPスコープを確認し、スコープにデフォルトゲートウェイ(003ルータ)オプションがあることを確認します。003 ルータ パラメータは、デバイスおよび PC のデフォルト ゲートウェイ フィールドに取り込まれます。スコープオプション3には、ゲートウェイにルーティングできるルータインターフェイスのIPアドレスが必要です。
Intercluster Trunk(ICT)用にトランスコーディングを設定する場合、Media Termination Point(MTP; メディア ターミネーション ポイント)が、トランクに関連付けられたメディア リソース グループおよびメディア リソース グループ リストに設定されていることを確認します。MTP が不要な場合に MTP を指定したり、必要であっても MTP の設定に失敗したりすると、ICT 設定のために単方向音声の問題を引き起こすことがわかっています。
Cisco IOSゲートウェイに複数のアクティブなIPインターフェイスがある場合、H.323シグナリングの一部は1つのIPアドレスから発信され、他の部分は別の送信元アドレスを参照できます。これにより、さまざまな問題が生じます。このような問題の 1 つに片通話の問題があります。
この問題を回避するために、H.323 シグナリングを特定の送信元アドレスにバインドできます。送信元アドレスは、物理インターフェイスまたは仮想インターフェイス(ループバック)のものを使用できます。インターフェイスコンフィギュレーションモードでh323-gateway voip bind srcaddr ip-addressコマンドを使用します。Cisco CallManager が参照先とする IP アドレスを持つインターフェイスでこのコマンドを設定します。
このコマンドは、Cisco IOS ソフトウェア リリース 12.1(2)T で導入されました。詳細については、『仮想インターフェイスの H.323 のサポート』を参照してください。
注意:Cisco IOSソフトウェアリリース12.2(6)には不具合があり、このリリースでは、このソリューションによって片通話の問題が実際に発生する可能性があります。詳細については、Cisco Bug ID CSCdw69681を参照してください。シスコの内部ツールおよび情報にアクセスできるのは、登録ユーザのみです。
シグナリングおよびメディア パケット用の送信元インターフェイスを指定しないと、Media Gateway Control Protocol(MGCP; メディア ゲートウェイ コントロール プロトコル)ゲートウェイで単方向音声が発生することがあります。mgcp bind media source-interface interface-idを発行すると、MGCPメディアを送信元インターフェイスにバインドできます コマンドを発行した後、mgcp bind control source-interface interface-id コマンドを使用して、アップグレードを実行します。コマンドを発行した後、Cisco CallManager で MGCP ゲートウェイをリセットします。
mgcp bind コマンドが有効になっていない場合でも、IP レイヤは最適なローカル アドレスを提供します。
mgcp bind コマンドのガイドラインは次のとおりです。
ゲートウェイにアクティブな MGCP コールがある場合、制御およびメディアに対する mgcp bind コマンドは拒否されます。
バインド インターフェイスがアップ状態ではない場合、コマンドを受け入れますが、インターフェイスがアップ状態になるまでは有効になりません。
バインド インターフェイスで IP アドレスが割り当てられていない場合、mgcp bind コマンドを受け入れますが、コマンドが有効になるのは、有効な IP アドレスが割り当てられた後に限られます。この間、MGCP コールがアップ状態である場合は、mgcp bind コマンドは拒否されます。
インターフェイスの手動シャットダウンまたは操作上の失敗が原因で、バインドされたインターフェイスがダウン状態になると、そのインターフェイスでのバインド動作はディセーブルになります。
Media Gateway Controller(MGC; メディア ゲートウェイ コントローラ)でバインドが設定されていない場合、MGCP 制御およびメディアの送信元として使用される IP アドレスが、最適に使用可能な IP アドレスです。
Telco またはスイッチに接続する Cisco IOS ゲートウェイがある場合、Telco またはスイッチの背後にある着信側デバイスがコールに応答するときに応答監視が正しく送信されることを確認します。応答監視の受信に失敗すると、Cisco IOS ゲートウェイが順方向の音声パスのカットスルー(オープン)に失敗します。この失敗により、単方向音声が発生します。回避策は、voice rtp send-recv on コマンドを発行することです。
詳細については、『Cisco IOS ゲートウェイおよびルータで voice rtp send-recv コマンドを使用した双方向音声の早期カットスルー』を参照してください。
RTP ストリームの開始時、逆方向の音声パスが確立されます。Cisco IOS ゲートウェイがリモート エンドから Connect メッセージを受信するまで、順方向の音声パスはカットスルーされません。
場合によっては、RTP チャネルがオープンされたらすぐに双方向音声パスの確立が必要なことがあり、この場合は、Connect メッセージを受信する前になります。このためには、voice rtp send-recv グローバル コンフィギュレーション コマンドを発行します。
この問題は、複数のCisco IOSルータまたはゲートウェイが音声パスに含まれ、圧縮RTP(cRTP)が使用されるトールバイパスなどのシナリオに適用されます。cRTPまたはRTPヘッダー圧縮は、帯域幅を取り戻すためにVoIPパケットヘッダーを小さくする方法です。cRTPは、VoIPパケット上の40バイトのIPまたはRTPヘッダーを2 ~ 4バイトに圧縮します。この圧縮により、cRTP を使用する G.729 エンコードされたコールの場合、約 12 kbps の帯域幅が空きます。cRTP の詳細は、『VoIP:コール単位の帯域幅の使用量』を参照してください。
cRTP は、ホップごとに圧縮解除と再圧縮を行って、ホップ単位に実行されます。ルーティングするために、各パケット ヘッダーを調べる必要があります。したがって、cRTP は IP リンクの両側でイネーブルにする必要があります。
また、cRTP がリンクの両端で意図したとおりに動作していることを確認することも重要です。Cisco IOS ソフトウェア リリースのレベルによっては、スイッチング パスおよび cRTP の同時サポートの点が異なります。
要約すると、次のような経過をたどっています。
Cisco IOS ソフトウェア リリース 12.0(5)T よりも前の Cisco IOS ソフトウェア リリースでは、cRTP はプロセス スイッチングされます。
Cisco IOS ソフトウェア リリース 12.0(7)T および Cisco IOS ソフトウェア リリース 12.1(1)T では、cRTP のファースト スイッチングおよび Cisco Express Forwarding(CEF)スイッチングのサポートが導入されました。
Cisco IOS ソフトウェア リリース 12.1(2)T で、アルゴリズムによってパフォーマンスが改善されました。
Cisco IOSソフトウェアプラットフォーム(Cisco IOSソフトウェアリリース12.1)でcRTPを実行する場合は、Cisco Bug ID CSCds08210がCisco IOSソフトウェアリリースに影響を与えないことを確認します。この不具合の症状は、RTP ヘッダー圧縮を使用して動作する VoIP および Fax Over IP が失敗します。
シスコの内部バグ情報およびツールにアクセスできるのは、登録ユーザのみです。
E1 インターフェイスまたは T1 インターフェイス上で show controller {e1 | t1}コマンドを使用してクロッキングを送信している場合は、音声ゲートウェイのクロッキング設定に矛盾がある可能性があります。『Cisco IOSベースの音声対応プラットフォームでのクロッキング設定』を参照して、音声ゲートウェイのクロッキング設定が正しいことを確認してください。
Network Address Translation(NAT; ネットワーク アドレス変換)を使用する場合は、ソフトウェア レベルの最小要件を満たす必要があります。以前のバージョンの NAT では Skinny プロトコル変換がサポートされていません。このような以前のバージョンでは、単方向音声の問題が発生します。
NAT を使用して Skinny および H.323 バージョン 2 を同時にサポートするには、Cisco IOS ゲートウェイに Cisco IOS ソフトウェア リリース 12.1(5)T 以降を稼働させる必要があります。詳細については、『Cisco CallManager に接続する IP Phone における NAT のサポート』を参照してください。
注:Cisco CallManagerがSkinnyシグナリングにデフォルトポート(2000)とは異なるTCPポートを使用する場合、NATルータを調整する必要があります。ip nat service skinny tcp port number グローバル コンフィギュレーション コマンドを発行します。
PIX Firewall 上で NAT と Skinny を同時に使用するために必要な最小ソフトウェア レベルは 6.0 です。詳細については、『Cisco PIX Firewall バージョン 6.0』を参照してください。
注:これらのレベルのソフトウェアは、ゲートキーパーのフルサポートに必要なすべてのRegistration, Admission, and Status(RAS)メッセージをサポートしているとは限りません。ゲートキーパーのサポートについては、この文章の適用範囲外です。
Cisco IOS ソフトウェアのコマンド voice-fastpath enable は、AS5350 および AS5400 の隠しグローバル コンフィギュレーション コマンドです。このコマンドはデフォルトでイネーブルになっています。ディセーブルにするには、no voice-fastpath enable グローバル コンフィギュレーション コマンドを発行します。
コマンドがイネーブルになっている場合、特定のコールに対してオープンになっている論理チャネルの IP アドレスと UDP ポート番号の情報をキャッシュします。このコマンドにより、RTP ストリームがアプリケーション層に到達しないようになります。代わりに、パケットは下位の層で転送されます。これによって、コールの量が多いシナリオでは、CPU 使用率を多少減少させることができます。
保留や転送などの補足サービスを使用する場合は、voice-fastpath コマンドにより、ルータがキャッシュされた IP アドレスおよび UDP ポートに音声を流すようになります。保留中のコールが再開された後、または転送が完了した後に生成される新しい論理チャネル情報は無視されます。この問題を回避するには、トラフィックが絶えずアプリケーション層に到達する必要があります。この結果、論理チャネルの再定義がアカウントに取り込まれ、新しい IP アドレスと UDP ポートのペアに音声が流れるようになります。したがって、補足サービスをサポートするには、voice-fastpath をディセーブルにしてください。
Cisco IP SoftPhone を使用すると、PC を Cisco IP Phone 7900 シリーズの電話のように動作させることができます。Virtual Private Network(VPN; バーチャル プライベート ネットワーク)を経由して企業ネットワークに接続するリモート ユーザは、単方向音声の問題を回避するために追加の設定をいくつか行う必要があります。これは、メディア ストリームが接続のエンド ポイントを識別する必要があるためです。
このソリューションは、ネットワーク音声設定で、ネットワーク アダプタの IP アドレスではなく、VPN の IP アドレスを設定することです。詳細は、『VPN 経由での Cisco IP SoftPhone の使用方法』を参照してください。
Cisco VPN 3002 Hardware Clientは、クライアントモードとネットワーク拡張モード(NEM)の2つのモードで動作できます。クライアントモードでは、Cisco VPN 3002クライアントの背後にあるすべてのホストは、VPN 3002クライアントの外部IPアドレスに変換されたポートアドレスになります。H.323はポートアドレス変換(PAT)では動作せず、IP電話がVPN 3002クライアントの背後に配置されると片通話になります。VPN 3002 が NEM で動作する場合、リモート ネットワークは、NAT ベースや PAT ベースの IP アドレスではなく、実際の IP アドレスを使用して相互に認識し合います。VPN 3002 が NEM で動作するように設定されている場合は、H.323 は動作可能です。つまり、VPN 3002 クライアントの背後にある IP Phone は、VPN 3002 が NEM で動作する場合だけ動作可能です。このため、VPN 3002 クライアントでの単方向音声を回避するには、NEM を使用するように VPN 3002 クライアントを設定します。
NEM を使用するように Cisco VPN 3002 Hardware Client を設定するには、[Configuration] > [Quick] > [PAT] を選択し、[PAT] ウィンドウで [No, use Network Extension mode] をクリックします。
詳細は、『Network Extension Mode で EzVPN を使用した Cisco IOS ルータへの Cisco VPN 3002 Hardware Client の設定』を参照してください。
パケット フローの確認に使用する便利な 2 つのコマンドに、debug cch323 rtp コマンドと debug voip rtp コマンドがあります。debug cch323 rtp コマンドは、ルータが送信(X)および受信(R)したパケットを表示します。大文字は、送信または受信の成功を示します。小文字はドロップされたパケットを示します。
voice-ios-gwy#debug cch323 rtp RTP packet tracing is enabled voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# !--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. Mar 3 23:46:23.690: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXXrrrrrrrrrrrrrrrr voice-ios-gwy# voice-ios-gwy# !--- This is an example of an answered call: voice-ios-gwy# voice-ios-gwy# *Mar 3 23:53:26.570: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr !--- At this point, the remote end picks up the phone. *Mar 3 23:53:30.378: ****** cut through in BOTH direction ***** XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR !--- This is the end of the conversation.
注:Cisco IOSソフトウェアリリース12.2(11)T以降では、debug cch323 rtpコマンドラインインターフェイス(CLI)コマンドがdebug voip rtpコマンドに置き換えられています。
voice-ios-gwy#debug voip rtp --------cut through in BOTH direction------------------- *Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002), pt=0, ts=4FFBF0, ssrc=8E5FC294 *Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C8D9, ssrc=1F1E5093 *Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002), pt=0, ts=4FFC90, ssrc=8E5FC294 *Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C979, ssrc=1F1E5093 *Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002), pt=0, ts=4FFD30, ssrc=8E5FC294 *Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CA19, ssrc=1F1E5093 *Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002), pt=0, ts=4FFDD0, ssrc=8E5FC294 *Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CAB9, ssrc=1F1E5093 *Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002), pt=0, ts=4FFE70, ssrc=8E5FC294 *Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CB59, ssrc=1F1E5093 *Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002), pt=0, ts=4FFF10, ssrc=8E5FC294 *Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CBF9, ssrc=1F1E5093 *Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002), pt=0, ts=4FFFB0, ssrc=8E5FC294 *Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CC99, ssrc=1F1E5093 *Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002), pt=0, ts=500050, ssrc=8E5FC294 *Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DEB9, ssrc=1F1E5093 *Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002), pt=0, ts=501270, ssrc=8E5FC294 *Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DF59, ssrc=1F1E5093 *Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002), pt=0, ts=501310, ssrc=8E5FC294 *Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DFF9, ssrc=1F1E5093
PIX Firewall を通過するコール トラフィック情報を集めることで、単方向コールのトラブルシューティングを行うことができます。PIX の capture コマンドを使用して、コール発生時にオープンして使用されたポートを確認できます。PIX Firewall を通過する VoIP トラフィックについては、『PIX ファイアウォールでの VoIP トラフィックの処理』を参照してください。
注:トラブルシューティングを行うために必要なキャプチャファイルを生成した後は、必ずcaptureコマンドを無効にしてください。
この問題は、MTP が必要な発信初期 SIP コール セットアップでのみ発生します。この場合、発信SIP INVITEメッセージにSDPオファーを含めることができます。この問題は、次のシナリオで発生する可能性があります。
SIP トランクで [Media Termination Point Required] がオンになっている発信 SIP トランク コール
IPv6 専用エンドポイントと IPv4 専用エンドポイント間のコール
MTPリソースが断続的にリークし、MTPリソースを必要とするSIPコールが失敗する可能性があります。RTMT から使用可能な MTP リソース数が 0 に達し、MTP が必要なコールごとに MTP 割り当て失敗回数が増加します。初期INVITEのSDP部分に誤ってa=inactiveが含まれている可能性があります。
この問題を解決するには、次の手順を実行します。
可能な場合は、SIP トランク設定の [Media Termination Point Required] をオフにします。
アーリー オファーが必要な場合は、アーリー オファーを設定しますが、[Media Termination Point Required] はオフのままにします。
IPv6 導入では、IPv6 専用エンドポイント以外のデュアル スタックを使用します。
注:この問題は、Cisco Bug ID CSCtk77040に記載されています。 シスコの内部バグツールおよび情報にアクセスできるのは、登録ユーザのみです。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
11-Oct-2001 |
初版 |