CUBE が PCA のボーダー要素として検出されないとき続くためにステップを解決して下さい
概要
この資料は Cisco Unified Border Element （CUBE）が主なコラボレーション保証（PCA）のボーダー要素として検出されないとき解決するために続かれるべきステップを記述したものです。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- PCA
- Cisco Unified Communications Manager（CUCM）
- CUBE
使用するコンポーネント
この文書に記載されている情報は主なコラボレーション保証に基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
CUBE が PCA のボーダー要素として検出されない場合続かれるべきステップ
PCA のボーダー要素として識別されるべき CUBE に関しては:
- a. 非CUCM 配備: これらの条件は満足するはずです:
条件- 1: デバイス モデルはのリストに-表 2.サポートされているプラットフォーム（http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) あるはずです。
条件 2: 戻り値が SipCfgPeerTable のための noSuchObject/noSuchInstance 以外もし SIP-UA-MIB。
- b. CUCM 配備: これらの条件は満足するはずです:
条件- 1: デバイス モデルはのリストに-表 2.サポートされているプラットフォーム（http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) あるはずです。
条件 2: 戻り値が SipCfgPeerTable のための noSuchObject/noSuchInstance 以外もし SIP-UA-MIB。
条件 3: デバイス IP アドレスは CUCM の 1 の SIP トランクと関連付ける必要があります。
CUBE SP として識別されるべきデバイスに関しては CUBE および CISCO_SESS_BORDER_CTRLR_CALL_STATS_MIB.csbSIPMthdCurrentStatsAdjName に応答する必要があると同時に最初に識別する必要があります（1.3.6.1.4.1.9.9.757.1.3.1.1）
これらの条件が満たされたらおよびそれでも PCA がボーダー要素としてデバイスを識別しなかったら、かどうか CUCM およびデバイスの設定確認して下さい。
CUCM に CUBE 統合の CUBE 側
第 1 CUBE を設定するとき、CUBE のような呼び出しをルーティングすることをルータが可能にして下さい。 このイメージは基本音声 サービスに CUBE の VoIP 設定を示します:
この設定についてのいくつかの重要な点はここにあります:
- 設定の最初の行はルータの CUBE を有効に する モード ボーダー要素です。 CUBE として動作するときいくつかのデバイスにこの設定がありません。
- 許可接続はすするために可能にします Session Initiation Protocol （SIP）呼び出しを受け入れ、SIP 呼び出しとしてルーティングすることを CUBE がすすります。 H323 のための同様にオプションがあります。
- ファクシミリ プロトコル t38 は ISR G2 ルータのためのデフォルト 設定です。 それは CUBE 設定のために必要ではないです。
- アーリー オファー（Early Offer） シナリオへの遅らせられたオファーの呼び出しをルーティングする早オファーによって強制される割り当て CUBE。 プロバイダほとんどすべてはアーリー オファー（Early Offer） SIP 呼び出しを必要とします。 実際に初期メディア カットスルー問題を避けるために CUCM からのアーリー オファー（Early Offer）を送信 することを推奨します。
- Midcall シグナリング passthru は一口に SIP 呼び出しのためだけです。 いくつかの補助サービスがはたらくことができるようにそれが必要となります。
- annexb すべての G729 は CUBE が G729r8 および G729br8 コーデックのための RFC 形式に準拠しないプロバイダとネゴシエートすれば最適です。
CUBE のダイヤルピア構成
CUBE のダイヤル ピアは Cisco IOSゲートウェイの他のダイヤル ピアのようです。 違いはこと 1 人の VOIPダイヤルピアからの他の VOIPダイヤルピアに呼び出しルートです。
ここに 2 人のダイヤル ピアがあることに注意して下さい: 着信および発信。 CUBE は 2 人のダイヤル ピアと常に一致します。 着信ダイヤルピアは CUCM または SIP プロバイダからの CUBE 観点から、あります。 発信 ダイヤル ピアは CUCM の方にまたは SIP プロバイダに差し向けられます。
ICisco は有効数字、外部電話番号 マスクおよび変換を通して CUCM のディジット操作のほとんどを行うことを推奨します。
ダイヤル ピアに関する詳細についてはボイス - Cisco IOS プラットフォームにおける着信および発信ダイヤルピアの照合方法について技術情報を参照して下さい。
ディジット操作は CUBE で Cisco IOSボイス ゲートウェイで実行されたと同様に実行されたことができます。 詳細についてはボイス トランスレーション プロファイル技術情報を使用して数変換を参照して下さい。
基本的な IP アドレッシング
CUBE の IP アドレッシングは他の Cisco IOSデバイスのと同じ方法達成されますが、どのインターフェイスから判別するためにルーティング テーブルを CUBE が SIP トラフィックのソースをたどるか使用します。 show ip route A.B.C.D コマンドは SIP トラフィックのソースをたどるためにインターフェイスについての情報を CUBE 使用提供したものです。 これは呼び出しが CUCM に送られるとき、そして呼び出しが SIP プロバイダに送られるとき重要です。 スタティック・ルートはこの作業を作るため必要であるかもしれません。
場合によっては、CUBE のループバックインターフェイスのような特定のインターフェイスに SIP を、結合 しなければならないかもしれません。 CUBE が特定のインターフェイスの SIP トラフィックを聞き取らないとき SIP バインディングにより副次的影響を、のような引き起こす場合があります。 Cisco はバインディングを使用し、がルーティング テーブルが決定するようにするこれは可能性のある常にではないですことを推奨します。 音声 サービス VoIP > SIP の下で、または個々のダイヤル ピアで SIP バインディングを加えることができます。 SIP バインディングは SIP バインド特集記事の設定で多く説明されます。
CUBE の Voice-Class コーデック
Voice-class コーデックは CUBE のために呼び出しが特定の VOIPダイヤルピアを使用するとき複数のコーデックを提供するために使用されます。 これはそれが CUBE のとき Cisco IOSボイス ゲートウェイにだったが、コーデックは 1 つの VOIPコール レグから他へのフィルタリングされます同じです。 それは着信ダイヤルピアおよび発信 ダイヤル ピア両方で利用可能であるコーデックを使用します。 両方とも一致するコーデックは送信 されたオファーです。 CUBE が Session Description Protocol （SDP）の SIP メッセージを受け取るとき、また voice-class コーデックとこれと一致します。 これは基づいてコーデックをフィルタリングするように届くものがに CUBE が SDP の SIP メッセージ、着信ダイヤルピアおよびアウトバウンドダイヤルピアからします。 他の SIP ユーザ エージェント（UA）は提供されるコーデックに応答します。
前のイメージの音声 クラス の コーデックは 3 コーデックが、g729r8、g711ulaw、または g711alaw 含まれています。 イメージは Cisco IOSゲートウェイが優先順位をつける順序でコーデックが遠端にどのように提供されるかそれらを示します。 Voice-class コーデックはダイヤル ピアに適用されます。
CUCM に CUBE 統合の CUCM 側
- トランクを、ナビゲートこの位置に CUCM 設定に追加するため:
- 『Add New』 を選択 し、ここに示されているように Session Initiation Protocol （SIP） トランクを設定することを続行して下さい:
- トランク の 設定 ページの中では、特定の CUCM サーバに受信コールを許可する適切なデバイス プールを選択することを忘れないようにして下さいコールを受け入れる。
トランクが作成されたら、ルートパターンが SIP ルートパターンか Route リスト/ルート グループ セットアップによってそれに正しくアクセスするようにして下さい。
リダイレクト転換ヘッダは受信かアウトバウンドコールのためにチェックすることができます。
外部番号が VOIPネットワークに転送されるとき、SIP は CUCM に中継された転換情報がメッセージを付いています誘います。 それは発生コーリングパーティを示します。 たとえば、コールフローが UC と統合、音声メールに入れば、UC は宛先 メールボックスとして最初の転換ソースを（外部は数を転送しました）使用します。 従ってそれらがサブスクライバ メールボックスの代りにデフォルト開始グリーティングを予想通り得る可能性があることは可能性のあるです。 それはトポロジーのコールフローおよび必要条件によってこれが設定に必要となる筈であるかどうか決まります。
- アーリー オファー（Early Offer）のための SIP プロファイルは頻繁にプロバイダに CUBE を接続するとき必要です。 トランクが別の Ciscoデバイスに接続する場合、遠端デバイスに基づいてメディア転送 プロトコル（MTP）挿入を、選択したいと思わないかもしれません。 このイメージは SIP プロファイル 位置をアーリー オファー（Early Offer）にボックスをどこで選択するか示し。
アーリー オファー（Early Offer）は頻繁に CUCM サーバを統合、他のサードパーティ製品に立方体になると起こるアーリー メディア（early media）問題の解決を助けます。 それはまたソリューション参照ネットワーク設計（SRND）の内で推奨されます。
プロファイルが修正される筈である場合既定値 の プロファイルの代りに使用するために新しいプロファイルを作成することが最善常にです。
注: このチェックボックスはエンドユーザは各コールで使用される MTP がありたいと思わないとき使用されます。
- コールフローに基づいて SIP セキュリティプロファイル内のプロトコルのための TCP/UDP から変更することは必要であるかもしれません。 SIP トランク セキュリティプロファイルへのこの変更を、ナビゲート行なうため > 非セキュア SIP トランク プロファイル:
呼び出しは失敗し、起こるが、この機能は修正することができますこと失敗の時に理解するためにそれが問題の原因ではないことを確認するために CUBE/CUCM トレースが必要となります。 ただし、これが修正されれば変更を発生させます、/再始動リセットするためにトランクなります。
- ある状況では、電話 設定に外部電話マスクはいくつかの Telco がコールが期待されたマスクなしでは続行しないようにしないのでコールが続行することができるように追加される必要があるかもしれません。 この修正を行うために、コーリングパーティ電話の Directory Number （DN） 設定 ページに、必要とします変更をボックスに行けば、リセット/再始動は変更の後の電話保存されます。
この設定が CUCM で作成されたら、PCA のクラスタ ディスカバリを始めて下さい。
デバイスは PCA のボーダー要素として今検出されます。
フィードバック