CUCM から CUBE への統合の設定例

概要

このドキュメントでは、Cisco Unified Communications Manager（CUCM）での Cisco Unified Border Element（CUBE）設定の基本について説明します。

前提条件

要件

シスコでは、システムにドメイン ネーム システム（DNS）が設定されていないこと、および次の項目に関する知識があることを推奨します。

• CUCM バージョン 8.6 からバージョン 10.x
• Cisco IOS^{® バージョン 15.1(2)T 以降}

注：IP アドレスは、ネットワーク内のアドレッシング方式によって異なります。

使用するコンポーネント

このドキュメントの情報は、任意の数の CUCM サーバおよび任意の Cisco Integrated Services Router（ISR）、ISR Generation 2（G2）または Cisco アグリゲーション サービス ルータ（ASR）を CUBE として利用できるという事実に基づいています。基本的な CUBE の動作に必要なデジタル信号プロセッサ（DSP）はありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

設定

CUBE 側での CUCM と CUBE の統合

CUBE を初期設定する際には、ルータを有効にして、CUBE などのコールがルーティングされるようにする必要があります。次の図に、CUBE での音声サービス VoIP の基本設定を示します。

この設定で重要な点は、次のとおりです。

• 設定の最初の行は、ルータ上で CUBE を有効にするための mode border-element です。一部のデバイスは、CUBE として動作する際にこの設定を使用しません。
  
  
• allow-connections sip to sip により、CUBE で Session Initiation Protocol（SIP）コールを受け入れて、これらのコールを SIP コールとしてルーティングできるようにします。H323 用のオプションもあります。
  
  
• fax protocol t38 は、ISR G2 ルータのデフォルト設定です。これは、CUBE 設定には不要です。
  
  
• early-offer forced により、CUBE で Delayed Offer のコールを Early Offer のシナリオにルーティングできるようにします。ほぼすべてのプロバイダーには、Early Offer SIP コールが必要です。実際のところ、Early Media Cut Through の問題を回避するために、CUCM から Early Offer を送信することを推奨します。
  
  
• midcall-signaling passthru は、SIP 間コール専用です。一部の補足サービスを機能させるためには、この設定が必要になります。
  
  
• G729r8 および G729br8 コーデックに関して RFC 形式に従っていないプロバイダーと CUBE がネゴシエーションする場合は、g729 annexb-all を使用するのが最適です。
  
  

CCUBE でのダイヤルピア設定

CUBE でのダイヤルピアは、Cisco IOS ゲートウェイでの他のダイヤルピアと同様です。異なる点は、VoIP ダイヤルピアから別の VoIP ダイヤルピアにコールがルーティングされることです。

CUBE でのダイヤルピアには着信ダイヤルピアと発信ダイヤルピアの 2 つがあることに注意してください。CUBE は常に 2 つのダイヤルピアを一致させます。CUBE の観点からは、着信ダイヤルピアとは CUCM または SIP プロバイダーからの着信ダイヤルピアを意味します。発信ダイヤルピアは、CUCM または SIP ダイヤルピアに向けて送信されます。

シスコでは、ディジット操作のほとんどを、有意な数字、外線電話番号マスク、および変換によって行うことを推奨しています。ダイヤルピアについて詳しくは、記事「Cisco IOS プラットフォームにおける着信および発信ダイヤル ピアの照合方法について」を参照してください。

CUBE でのディジット操作は、Cisco IOS 音声ゲートウェイで実行する場合と同じように実行できます。詳細については、記事「ボイス トランスレーション プロファイルを使用した番号変換」を参照してください。

基本的な IP アドレッシング

CUBE での IP アドレッシングは他の Cisco IOS デバイスでの場合と同様に行われますが、CUBE はルーティング テーブルを使用して SIP トラフィックの送信元インターフェイスを判別します。CUBE が SIP トラフィックを送信するために使用するインターフェイスについての情報は、show ip route A.B.C.D コマンドで表示できます。この情報は、コールが CUCM および SIP プロバイダーに送信される際に重要となります。これらのコールを正常に送信するには、スタティック ルートが必要になる場合もあります。

場合によっては、SIP を特定のインターフェイス（たとえば、CUBE 上のループバック インターフェイスなど）にバインドする必要があります。CUBE が特定のインターフェイスで SIP トラフィックをリッスンしない場合などに、SIP のバインディングで副次作用が生じることがあります。シスコでは、バインディングを使用せずに、ルーティング テーブルに決定させることを推奨していますが、これは常に可能であるとは限りません。SIP のバインディングは、[Voice Service VoIP] > [SIP] で適用することも、個々のダイヤルピアで適用することもできます。SIP のバインディングについて詳しくは、記事「SIP バインド機能の設定」を参照してください。

CUBE での音声クラス コーデック

コールが特定の VoIP ダイヤルピアを使用する場合に複数のコーデックをオファーできるよう、CUBE では音声クラス コーデックが使用されます。音声クラス コーデックは Cisco IOS 音声ゲートウェイでの場合と同じですが、CUBE の場合、これらのコーデックは VoIP コール レッグから別の VoIP コール レッグにフィルタリングされます。使用されるコーデックは、着信ダイヤルピアと発信ダイヤルピアの両方で有効です。両方と一致するコーデックがオファーとして送信されます。CUBE は Session Description Protocol（SDP）を使用した SIP メッセージを受信した場合も、そのメッセージを音声クラス コーデックと照合します。これにより、CUBE は SDP を使用した SIP メッセージで受け取った内容、着信ダイヤルピア、および発信ダイヤルピアを基準にコーデックをフィルタリングできます。それによって、オファーされたコーデックに、相手先の SIP ユーザ エージェント（UA）が応答します。

上記の図の音声クラス コーデックには、g729r8、g711ulaw、g711alaw という 3 つのコーデックが示されています。これらのコーデックは、Cisco IOS ゲートウェイが相手先に優先してオファーする順に示されています。  音声クラス コーデックは、ダイヤルピアに適用されます。

Cisco IOS 電話料金詐欺行為防止アプリケーション

Cisco IOS の電話料金詐欺行為防止アプリケーションは望ましくない SIP アクセスを防止するのに役立ちますが、適切に計画して使用しなければ、通常の動作に問題が発生する可能性があります。Cisco IOS の電話料金詐欺行為防止アプリケーションを使用することで、コール（H323 または SIP）を発信するためにルータと通信することを許可するデバイスを指定できます。ダイヤルピアでセッション ターゲットとして使用される IP アドレスは、自動的に Cisco IOS 音声ゲートウェイへのコール送信が許可されるため、追加の設定を行う必要はありません。これらの IP アドレスには、通常、環境内の SIP プロバイダーと CUCM サーバのすべてが含まれますが、必ずそうであるとも限りません。自動的に許可されない場合は、手動で CUBE に追加する必要があります。メディア アドレスではなく、シグナリング アドレスだけを追加する必要があります。詳細については、記事「IOS Release 15.1(2)T の電話ハッカーの侵入阻止機能」を参照してください。

CUCM 側での CUCM と CUBE の統合

1. トランクを CUCM 設定に追加するには、以下の図に示す場所に移動します。
   
   

   

   
   
   
2. [Add New] を選択し、以下に示す SIP トランクの設定を続けます。
   
   

   

   
   
   
3. トランク設定ページでは必ず、コールを受け入れる特定の CUCM サーバへの着信コールを許可する適切なデバイス プールを選択します。
   
   

   

   
   
   トランクを作成したら、SIP ルート パターンまたはルート リスト/ルート グループ設定で、ルート パターンが正常にそのトランクにアクセスできるようになっていることを確認します。
   
   着信コールまたは発信コールで [Redirecting Diversion Header] をオンにできます。
   
   外線番号が VoIP ネットワークに転送される際は、SIP 招待メッセージに CUCM への中継転送情報が追加されます。これに、発呼側が示されます。たとえば、Cisco Unity Connection（UC）と統合されているコール フローがボイスメールに到達すると、UC は当初の転送元（外部転送番号）を宛先メールボックスとして使用します。したがって、加入者のメールボックスの代わりにデフォルトの開始メッセージが表示される可能性があります。設定で必要になるかどうかは、トポロジのコール フローと要件によって決まります。
   
   

   

   
   
   
4. CUBE をプロバイダーに接続する場合は、通常、Early Offer の SIP プロファイルが必要になります。トランクを別のシスコ デバイスに接続する場合、遠端デバイスによっては、Media Transport Protocol（MTP）挿入を選択しないほうが好ましいこともあります。次の図に、SIP プロファイルの場所と選択する Early Offer のボックスの場所を示します。
   
   

   

   
   
   

   

   
   
   大抵の場合、Early Offer は、CUCM サーバと CUBE を他のサードパーティ製品に統合する際に生じるメディア問題の早期解決に役立ちます。ソリューション リファレンス ネットワーク デザイン（SRND）でも Early Offer が推奨されています。
   
   プロファイルが変更されることになる場合は、常に、デフォルト プロファイルの代わりに使用する新しいプロファイルを作成することが最善策となります。 
   
   

   注：このチェックボックスを使用するのは、すべてのコールで MTP が使用されないことをエンドユーザが選択する場合です。

   
   
   
5. コール フローに応じて、SIP セキュリティ プロファイル内でプロトコルを TCP/UDP から変更しなければならない場合があります。この変更を行うには、[SIP Trunk Security Profiles] > [Non Secure SIP Trunk Profile] に移動します。
   
   

   

   
   
   

   

   
   
   コールが失敗した理由を突き止めるには CUBE/CUCM トレースが必要になりますが、この機能を変更することで、これが問題の原因ではないことを確認できます。ただし、この機能を変更した後、変更を適用するにはトランクをリセット/再起動する必要があります。
   
   
6. 一部の電話会社では、期待するマスクが使用されていなければコールの続行を許可しないため、状況によっては、コールを続行するために電話機の設定に外線電話番号マスクの設定を追加する必要があります。この変更を行うには、発呼側電話機の [Directory Number] 設定ページに移動して、ボックスに必要な変更を加えます。その変更を保存した後、電話機をリセット/再起動します。
   
   

   

確認

設定が正常に機能していることを確認するには、テスト コールを発信します。テスト コールが失敗した場合は、問題を理解するために詳細な CUCM サービス トレースまたは CUBE トレースを取得します。

トラブルシュート

現在、この設定に関する特定のトラブルシューティング情報はありません。