概要

Webex Calling は現在、次の 2 つのバージョンの Local Gateway をサポートしています。

  • ローカルゲートウェイ

  • Webex for Government のローカル ゲートウェイ

  • 始める前に、Webex Calling の構内ベースの公衆交換電話網 (PSTN) とローカル ゲートウェイ (LGW) の要件を理解しておいてください。詳細については 、「設定されたアーキテクチャ」Webex Calling を参照してください。

  • この記事では、専用のローカル ゲートウェイ プラットフォームが配置されているが、既存の音声構成がないと仮定しています。既存の PSTN ゲートウェイまたは CUBE Enterprise 展開を変更して、Webex Calling のローカル ゲートウェイ機能として使用する場合は、構成に十分注意してください。変更によって既存のコールフローと機能が中断されないようにしてください。

手順には、個々のコマンド オプションの詳細を確認できるコマンド リファレンス ドキュメントへのリンクが含まれています。特に明記されていない限り、すべてのコマンド リファレンス リンクは Webex Managed Gateways コマンド リファレンス に移動します (明記されている場合、コマンド リンクは Cisco IOS Voice コマンド リファレンスに移動します)。これらのガイドはすべて、「Cisco Unified Border Element コマンド リファレンス」からアクセスできます。

サポートされているサードパーティの SBC の詳細については、それぞれの製品リファレンス ドキュメントを参照してください。

システム トランクのローカル ゲートウェイを設定するための 2 つの Webex Calling があります。

  • 登録ベースのトランク

  • 証明書ベースのトランク

登録ベースのローカル ゲートウェイ または 証明書ベースのローカル ゲートウェイ のいずれかのタスク フローを使用して、Webex Calling トランクのローカル ゲートウェイを設定します。

さまざまなトランク タイプの詳細については、 ローカル ゲートウェイの使用を開始する を参照してください。コマンドラインインターフェース (CLI) を使用して、ローカル ゲートウェイ自体で以下の手順を実行します。トランクのセキュリティ保護にはセッション開始プロトコル (SIP) とトランスポート層セキュリティ (TLS) トランスポートを使用し、ローカル ゲートウェイと Webex Calling 間のメディアのセキュリティ保護にはセキュア リアルタイム プロトコル (SRTP) を使用します。

  • ローカルゲートウェイとして CUBE を選択します。Webex for Government は現在、サードパーティのセッション ボーダー コントローラー (SBC) をサポートしていません。最新のリストを確認するには、 Local Gateway の使用を開始するを参照してください。

  • すべての Webex for Government ローカル ゲートウェイに Cisco IOS XE Dublin 17.12.1a 以降のバージョンをインストールします。
  • Webex for Government がサポートするルート証明機関 (CA) のリストを確認するには、 Webex for Government のルート証明機関を参照してください。

  • Webex for Government のローカル ゲートウェイの外部ポート範囲の詳細については、 Webex for Government (FedRAMP) のネットワーク要件を参照してください。

Webex for Government のローカル ゲートウェイは以下をサポートしていません。

  • STUN/ICE-Lite メディアパスの最適化

  • ファックス(T.38)

Webex for Government で Webex Calling トランクのローカル ゲートウェイを構成するには、次のオプションを使用します。

  • 証明書ベースのトランク

証明書ベースのローカル ゲートウェイ の下のタスク フローを使用して、Webex Calling トランクのローカル ゲートウェイを設定します。証明書ベースのローカル ゲートウェイを構成する方法の詳細については、 Webex Calling 証明書ベースのトランクを構成するを参照してください。

Webex for Government のローカル ゲートウェイをサポートするには、FIPS 準拠の GCM 暗号を設定する必要があります。そうでない場合、通話のセットアップは失敗します。設定の詳細については、 Webex Calling 証明書ベースのトランクを構成するを参照してください。

Webex for Government は登録ベースのローカル ゲートウェイをサポートしていません。

このセクションでは、登録 SIP トランクを使用して、Cisco Unified Border Element (CUBE) を Webex Calling のローカル ゲートウェイとして設定する方法について説明します。このドキュメントの最初の部分では、単純な PSTN ゲートウェイを構成する方法を説明します。この場合、PSTN からのすべての通話は Webex Calling にルーティングされ、Webex Calling からのすべての通話は PSTN にルーティングされます。以下の画像は、このソリューションと、それに従う高レベルの通話ルーティング構成を示しています。

この設計では、次の主要な構成が使用されます。

  • 音声クラスのテナント: トランク固有の構成を作成するために使用されます。

  • 音声クラスURI: 着信ダイヤルピアの選択のために SIP メッセージを分類するために使用されます。

  • 着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループを使用して発信ルートを決定します。

  • ダイヤルピアグループ: 転送コール ルーティングに使用される発信ダイヤルピアを定義します。

  • 発信ダイヤルピア: 送信 SIP メッセージを処理し、必要なターゲットにルーティングします。

通話ルーティング from/to 公衆回線 to/from Webex Calling 構成ソリューション

IP と SIP は PSTN トランクのデフォルト プロトコルになっていますが、TDM (時分割多重化) ISDN 回線も依然として広く使用されており、Webex Calling トランクでサポートされています。TDM-IP コール フローを備えたローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグ コール ルーティング プロセスを使用する必要があります。このアプローチでは、下の図に示すように、Webex Calling と PSTN トランクの間に内部ループバック ダイヤルピアのセットを導入することで、上記のコール ルーティング構成を変更します。

Webex Calling と PSTN トランク間の内部ループバック ダイヤルピアのセットを使用したコール ルーティング構成

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、次の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling 通話の集中ルーティングと処理を提供します。

ソリューション図では、Unified Communications Manager がすべての PSTN および Webex Calling 通話の集中ルーティングと処理を提供していることが示されています。

このドキュメント全体では、次の図に示すホスト名、IP アドレス、およびインターフェースが使用されます。

コールルーティング構成ソリューションで使用されるホスト名、IPアドレス、およびインターフェース

このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの構成を完了します。

  • ステップ 1:ルーターのベースライン接続とセキュリティを構成する

  • ステップ 2: Webex 通話トランクを設定する

    必要なアーキテクチャに応じて、次のいずれかを実行します。

  • ステップ 3: SIP PSTNトランクを使用してローカルゲートウェイを構成する

  • ステップ 4: ローカル ゲートウェイを既存の Unified CM 環境で構成する

    または:

  • ステップ 3: TDM PSTNトランクを使用したローカルゲートウェイの設定

ベースライン構成

Cisco ルーターを Webex Calling のローカル ゲートウェイとして準備するための最初の手順は、プラットフォームを保護し、接続を確立するベースライン構成を構築することです。

  • すべての登録ベースのローカル ゲートウェイ展開には、Cisco IOS XE 17.6.1a 以降のバージョンが必要です。Cisco IOS 17.12.2 以降が推奨されます。推奨バージョンについては、 Cisco Software Research ページを参照してください。プラットフォームを検索し、 推奨される リリースのいずれかを選択します。

    • ISR4000 シリーズ ルータは、ユニファイド コミュニケーションとセキュリティ テクノロジーのライセンスの両方を使用して設定する必要があります。

    • 音声カードまたは DSP を搭載した Catalyst Edge 8000 シリーズ ルータには、DNA Advantage ライセンスが必要です。音声カードまたは DSP のないルーターには、最低限 DNA Essentials ライセンスが必要です。

  • ビジネス ポリシーに従ったプラットフォームのベースライン構成を構築します。特に、次の項目を設定して検証します。

    • NTP

    • Acl

    • ユーザー認証とリモートアクセス

    • DNS

    • IP ルーティング

    • IPアドレス

  • Webex Calling へのネットワークでは IPv4 アドレスを使用する必要があります。

  • Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。

構成

1

有効かつルーティング可能な IP アドレスがすべてのレイヤー 3 インターフェイスに割り当てられていることを確認します。次に例を示します。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルーター上の登録と STUN 資格情報を保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes

3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を構成するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントには証明書は必要ありません (証明書ベースのトランクの場合に必要)。


crypto pki trustpoint EmptyTP 
 revocation-check none
4

次の設定コマンドを使用して、TLS1.2 の排他性を有効にし、デフォルトのトラストポイントを指定します。登録のための信頼性の高い安全な接続を確保するために、トランスポート パラメータを更新します。

cn-san-validate server コマンドは、テナント 200 で設定されたホスト名が、送信プロキシから受信した証明書の CN フィールドまたは SAN フィールドのいずれかに含まれている場合に、ローカル ゲートウェイが接続を許可することを確認します。

  1. tcp-retry count を 1000 (5 ミリ秒の倍数)に設定します = 5秒)。

  2. timer connection established コマンドを使用すると、LGW が次の利用可能なオプションを検討する前にプロキシとの接続を確立するために待機する時間を調整できます。このタイマーのデフォルトは 20 秒、最小は 5 秒です。最初は低い値から始めて、ネットワークの状況に合わせて必要に応じて値を増やします。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000

5

Webex Calling で使用される IdenTrust Commercial Root CA1 証明書を含む Cisco ルート CA バンドルをインストールします。 crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアしてから、新しい証明書バンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の構成を追加します。

ip http クライアント プロキシサーバー yourproxy.com プロキシポート 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
1

コントロール ハブ内の既存の場所に対して登録ベースの PSTN トランクを作成します。トランクが作成されると提供されるトランク情報をメモします。図で強調表示されている詳細は、このガイドの構成手順で使用されます。詳細については、 「 Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

PSTNトランク登録済み
2

CUBE を Webex Calling ローカル ゲートウェイとして設定するには、次のコマンドを入力します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced  

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y
  • 通話料金詐欺を防ぐために、信頼できるアドレス リストには、ローカル ゲートウェイが正当な VoIP 通話を期待するホストとネットワークのリストが定義されています。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストにない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に構成されたダイヤルピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを構成するときは、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。また、Unified Communications Manager サーバー (使用されている場合) と PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限付き cone NAT を備えたファイアウォールの背後にある場合は、Webex Calling 対応インターフェイス上の IP アドレスの信頼済みリストを無効にすることをお勧めします。ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

モード境界要素

プラットフォーム上で Cisco Unified Border Element (CUBE) 機能を有効にします。

メディア統計

ローカル ゲートウェイ上のメディア監視が可能です。

メディアバルク統計

一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。

これらのコマンドの詳細については、 メディアを参照してください。

allow-connections sip to sip

CUBE の基本的な SIP バックツーバック ユーザー エージェント機能を有効にします。詳細については、 接続を許可するを参照してください。

デフォルトでは、T.38 FAX トランスポートは有効になっています。詳細については、 FAXプロトコルT38 (音声サービス)を参照してください。

スタン

STUN (NAT を介した UDP のセッション トラバーサル) をグローバルに有効にします。

  • ローカル ゲートウェイの STUN バインディング機能により、ローカルで生成された STUN 要求をネゴシエートされたメディア パス経由で送信できるようになります。これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、 stun flowdata agent-id および stun flowdata shared-secretを参照してください。

非対称ペイロードフル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを構成します。詳細については、 非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つのではなく、初期 INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、 early-offerを参照してください。

3

voice class codec 100 を設定し、すべてのトランクに対して G.711 コーデックのみを許可します。このシンプルなアプローチは、ほとんどの展開に適しています。必要に応じて、発信側システムと着信側システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用した トランスコーディング を含む、より複雑なソリューションもサポートされていますが、このガイドには含まれていません。


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラスコーデック100

SIP トランク通話に優先コーデックのみを許可するために使用されます。詳細については、 音声クラスコーデックを参照してください。

4

Webex Callingトランク上でICEを有効にするには、 voice class stun-usage 100 を設定します。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

スタン使用アイスライト

可能な限りメディア最適化を可能にするために、すべての Webex Calling 対応ダイヤルピアに対して ICE-Lite を有効にするために使用されます。詳細については、 voice class stun usage および stun usage ice liteを参照してください。

メディアの最適化は可能な限りネゴシエートされます。通話に録音などのクラウド メディア サービスが必要な場合は、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーおよびアンサーメッセージのSDPでCUBEが提供する唯一のSRTP暗号スイートとしてSHA1_80を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、 voice class srtp-cryptoを参照してください。

6

宛先トランク パラメータに基づいてローカル ゲートウェイ トランクへの通話を識別するパターンを設定します。


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

以下は、設定のフィールドの説明です。

音声クラス URI 100 SIP

着信 SIP 招待を着信トランク ダイヤルピアに一致させるパターンを定義します。このパターンを入力するときは、dtg=に続けてトランクを使用します。 OTG/DTG トランク作成時にコントロールハブで提供された値。詳細については、 voice class uriを参照してください。

7

sip profile 100を設定します。これは、SIP メッセージが Webex Calling に送信される前に変更するために使用されます。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "" "" 
 rule 50 response ANY sip-header To modify "" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • ルール10から70と90

    通話シグナリングに使用される SIP ヘッダーが、Webex プロキシに必要な SIP スキームではなく、SIP を使用することを確認します。CUBE を SIP を使用するように構成すると、安全な登録が使用されるようになります。

  • ルール80

    Fromヘッダーを変更してトランクグループを含める OTG/DTG 企業内のローカル ゲートウェイ サイトを一意に識別するために、コントロール ハブから識別子を取得します。

米国またはカナダの PSTN プロバイダーは、 Webex Calling でのスパムまたは詐欺通話の表示 の記事に記載されている追加の構成により、スパムおよび詐欺通話に対する発信者 ID 検証を提供できます。

8

Webex Calling トランクを設定します。

  1. Webex Calling トランクに特に必要な構成を定義およびグループ化するには、 voice class tenant 100 を作成します。特に、以前に Control Hub で提供されたトランク登録の詳細は、以下に詳述されているように、この手順で使用されます。このテナントに関連付けられたダイヤルピアは、後でこれらの構成を継承します。

    次の例では、このガイドの目的に合わせて手順 1 で示した値 (太字で表示) を使用しています。これらを設定内のトランクの値に置き換えます。

    
    voice class tenant 100
      registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
      credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
      authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
      authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
      no remote-party-id
      sip-server dns:98027369.us10.bcld.webex.com
      connection-reuse
      srtp-crypto 100
      session transport tcp tls 
      no session refresh
      url sips 
      error-passthru
      rel1xx disable
      asserted-id pai 
      bind control source-interface GigabitEthernet0/0/1
      bind media source-interface GigabitEthernet0/0/1
      no pass-thru content custom-sdp 
      sip-profiles 100 
      outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
      privacy-policy passthru
    

    以下は、設定のフィールドの説明です。

    音声クラステナント 100

    Webex Calling トランクにのみ使用される一連の構成パラメータを定義します。詳細については、 音声クラステナントを参照してください。

    レジストラ dns:98027369.us10.bcld.webex.com スキーム SIP 有効期限 240 リフレッシュ率 50 TCP TLS

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、 レジストラを参照してください。

    ここでは、コントロール ハブのドメイン登録値を使用するようにしてください。

    資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ レルム ブロードワークス

    トランク登録認証の資格情報。詳細については、 資格情報 (SIP UA)を参照してください。

    必ず Line/Port ここで、Control Hub からそれぞれホスト、認証ユーザー名、認証パスワードの値を入力します。

    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ レルム ブロードワークス
    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ レルム 98027369.us10.bcld.webex.com

    コールの認証の課題。詳細については、 認証(ダイヤルピア)を参照してください。

    ここでは、Control Hub の認証ユーザー名、認証パスワード、レジストラ ドメインの値をそれぞれ使用していることを確認してください。

    no remote-party-id

    Webex Calling は PAI をサポートしており、これは asserted-id paiを使用して有効化されるため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。詳細については、 remote-party-idを参照してください。

    SIPサーバーのDNS: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバーを構成します。トランクを作成したときに、Control Hub で提供された Edge プロキシ SRV アドレスを使用します。

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。詳細については、 connection-reuseを参照してください。

    srtp-crypto 100

    SRTPコールレッグ(接続)の優先暗号スイートを設定します(手順5). 詳細については、 voice class srtp-crypto を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。詳細については、 session-transportを参照してください。

    セッション更新なし

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、 セッションの更新を参照してください。

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、 error-passthruを参照してください。

    rel1xx 無効化

    Webex Calling トランクの信頼性の高い暫定応答の使用を無効にします。詳細については、 rel1xxを参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、Webex Calling トランクでこれがどのように使用されるかを制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE に P-Asserted-Identity (PAI) ヘッダーが含まれます。

    このコマンドが設定されている場合、PAIヘッダーの発信者情報が発信元と発信者情報に使用されます。 PAI/Remote-Party-ID ヘッダー。

    このコマンドが設定されていない場合、Fromヘッダーの発信者情報が、発信Fromと PAI/Remote-Party-ID ヘッダー。

    詳細については、 asserted-idを参照してください。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージの送信元インターフェイスと関連 IP アドレスを設定します。詳細については、 bindを参照してください。

    メディアソースインターフェースをバインドする GigabitEthernet0/0/1

    WebexCalling に送信されるメディアの送信元インターフェイスと関連 IP アドレスを設定します。詳細については、 bindを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。このコマンドの詳細については、 パススルーコンテンツを参照してください。

    SIPプロファイル 100

    SIPをSIPに変更して修正する Line/Port sip-profiles 100で定義されているINVITEおよびREGISTERメッセージ用。詳細については、 voice class sip-profilesを参照してください。

    アウトバウンドプロキシ dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。トランクを作成したときにコントロール ハブで提供された送信プロキシ アドレスを挿入します。詳細については、 outbound-proxyを参照してください。

    privacy-policy passthru

    受信したメッセージからのプライバシー値を次のコール レッグに渡すために、トランクのプライバシー ヘッダー ポリシー オプションを設定します。詳細については、 プライバシーポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     incoming uri request 100
     voice-class codec 100
     dtmf-relay rtp-nte
     voice-class stun-usage 100
     no voice-class sip localhost
     voice-class sip tenant 100
     srtp
     no vad
    

    以下は、設定のフィールドの説明です。

    
    dial-peer voice 100 voip
      description Inbound/Outbound Webex Calling
    

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    最大接続数 250

    LGW と Webex Calling 間の同時着信および発信コールの数を制限します。登録トランクの場合、設定される最大値は 250 にする必要があります。より低い値が展開に適している場合は、その値を使用してください。ローカル ゲートウェイの同時通話制限の詳細については、 ローカル ゲートウェイの使用開始 ドキュメントを参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。詳細については、 destination-pattern (interface)を参照してください。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバーが継承され、このダイヤル ピアからの通話の宛先として使用されることを示します。詳細については、 セッション ターゲット (VoIP ダイヤル ピア)を参照してください。

    受信URIリクエスト 100

    VoIP ダイヤル ピアを着信コールの Uniform Resource Identifier (URI) に一致させるために使用される音声クラスを指定します。詳細については、 受信 URIを参照してください。

    音声クラスコーデック 100

    共通コーデック フィルタ リスト 100 を使用するようにダイヤルピアを設定します。詳細については、 voice-class codecを参照してください。

    ボイスクラス スタン使用率 100

    ローカル ゲートウェイ上でローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。STUN は、メディア トラフィック用のファイアウォール ピンホールを開くのに役立ちます。詳細については、 voice-class stun-usageを参照してください。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    音声クラス SIP テナント 100

    ダイヤルピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータはダイヤルピア レベルで上書きされる場合があります。

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

テナント 100 を定義し、SIP VoIP ダイヤルピアを構成すると、ゲートウェイは Webex Calling への TLS 接続を開始します。この時点で、アクセス SBC は証明書をローカル ゲートウェイに提示します。ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling アクセス SBC 証明書を検証します。証明書が認識されると、ローカル ゲートウェイと Webex Calling アクセス SBC の間に永続的な TLS セッションが確立されます。ローカル ゲートウェイは、この安全な接続を使用して Webex アクセス SBC に登録できるようになります。登録の認証が要求された場合:

  • レスポンスでは、 credentials 構成の usernamepasswordrealm パラメータが使用されます。

  • SIP プロファイル 100 の変更ルールは、SIPS URL を SIP に戻すために使用されます。

アクセス SBC から 200 OK を受信すると、登録は成功します。

ローカルゲートウェイを使用した Webex Calling の認証と登録のフロー図

上記で Webex Calling へのトランクを構築したら、次の設定を使用して SIP ベースの PSTN プロバイダーへの暗号化されていないトランクを作成します。

サービス プロバイダーが安全な PSTN トランクを提供している場合は、Webex Calling トランクについて上記で説明したのと同様の構成に従うことができます。CUBE は安全な通話ルーティングをサポートします。

TDMを使用している場合 / ISDN PSTN トランクの場合は、次のセクション TDM PSTN トランクを使用してローカル ゲートウェイを構成するに進んでください。

Cisco TDM-SIP ゲートウェイで PSTN コール レッグ用の TDM インターフェイスを設定するには、 ISDN PRI の設定を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス URI を構成します。


voice class uri 200 sip
  host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス URI 200 SIP

着信 SIP 招待を着信トランク ダイヤルピアに一致させるパターンを定義します。このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、 voice class uriを参照してください。

2

次の IP PSTN ダイヤルピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

以下は、設定のフィールドの説明です。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ 200 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。詳細については、 ダイヤルピア音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。詳細については、 destination-pattern (interface)を参照してください。

session protocol sipv2

このダイヤルピアが SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

セッションターゲット IPv4: 192.168.80.13

PSTN プロバイダーに送信される通話のターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名のいずれかになります。詳細については、 セッション ターゲット (VoIP ダイヤル ピア)を参照してください。

200 経由の URI の受信

INVITE VIA ヘッダー URI を使用して、このダイヤルピアへの着信コールを一致させるために使用される音声クラスを指定します。詳細については、 受信 URLを参照してください。

音声クラス SIP アサート ID PAI

(オプション) P-Asserted-Identity ヘッダー処理をオンにし、PSTN トランクでこれがどのように使用されるかを制御します。このコマンドを使用すると、着信ダイヤルピアから提供された発信側 ID が、発信 From ヘッダーと P-Asserted-Identity ヘッダーに使用されます。このコマンドを使用しない場合、着信ダイヤルピアから提供された発信側 ID が、発信 From ヘッダーと Remote-Party-ID ヘッダーに使用されます。詳細については、 voice-class sip asserted-idを参照してください。

バインド制御ソースインターフェイス GigabitEthernet0/0/0

PSTN に送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

メディアソースインターフェースをバインドする GigabitEthernet0/0/0

PSTN に送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

音声クラスコーデック 100

共通コーデックフィルタリスト 100を使用するようにダイヤルピアを設定します。詳細については、 voice-class codecを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

3

Webex Calling と PSTN 間の通話のみをルーティングするようにローカル ゲートウェイを設定する場合は、次の通話ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを構成する場合は、次のセクションに進んでください。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN に通話をルーティングします。Webex Calling への発信ダイヤルピア 100 を使用して DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN への発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
    voice class dpg 100 
     description Route calls to Webex Calling 
     dial-peer 100 
    voice class dpg 200 
     description Route calls to PSTN 
     dial-peer 200

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、 voice-class dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN へ、また PSTN から Webex への通話をルーティングします。

    
    dial-peer voice 100
     destination dpg 200
    dial-peer voice 200
     destination dpg 100 

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    この着信ダイヤルピアに提示された通話の発信処理に使用するダイヤルピア グループ、つまりダイヤルピアを指定します。

    これでローカル ゲートウェイの構成は完了です。CUBE 機能を初めて構成する場合は、構成を保存してプラットフォームを再ロードします。

Webex Calling へのトランクを構築したら、次の設定を使用して、ループバック コール ルーティングを備えた PSTN サービス用の TDM トランクを作成し、Webex コール レッグでのメディア最適化を可能にします。

IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア (手順 2 および 3 を参照) を使用します。

1

ループバック ダイヤルピア設定では、ダイヤルピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN 間でコールが正しく渡されるようにします。コール ルーティング タグを追加および削除するために使用される次の変換ルールを構成します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12 

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。10 進数を超える数字 (「A」) は、トラブルシューティングを明確にするために使用されます。

この設定では、translation-profile 100 によって追加されたタグは、Webex Calling からの通話をループバック ダイヤルピア経由で PSTN に誘導するために使用されます。同様に、translation-profile 200 によって追加されたタグは、PSTN からの通話を Webex Calling に誘導するために使用されます。翻訳プロファイル 11 と 12 は、通話をそれぞれ Webex トランクと PSTN トランクに配信する前にこれらのタグを削除します。

この例では、Webex Callingからの着信番号が次のように表示されることを前提としています。 +E.164 形式。ルール100は先頭の + 有効な着信番号を維持するため。ルール 12 では、タグを削除するときに国内または国際ルーティング番号を追加します。ローカル ISDN 国内ダイヤル プランに適した数字を使用します。

Webex Calling が国別形式で番号を表示する場合は、ルール 100 と 12 を調整して、ルーティング タグをそれぞれ追加および削除するだけです。

詳細については、 voice translation-profile および voice translation-ruleを参照してください。

2

使用するトランク タイプとプロトコルに応じて、TDM 音声インターフェイス ポートを構成します。詳細については、 ISDN PRI の設定を参照してください。たとえば、デバイスの NIM スロット 2 にインストールされているプライマリ レート ISDN インターフェイスの基本構成には、次のようなものがあります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31 
3

次の TDM PSTN ダイヤルピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

以下は、設定のフィールドの説明です。


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 200 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。詳細については、 ダイヤルピア音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。詳細については、 destination-pattern (interface)を参照してください。

翻訳プロファイル受信 200

着信番号にコール ルーティング タグを追加する変換プロファイルを割り当てます。

直通ダイヤル

セカンダリダイヤルトーンを提供せずに通話をルーティングします。詳細については、 direct-inward-dialを参照してください。

ポート 0/2/0:15

このダイヤルピアに関連付けられた物理音声ポート。

4

TDM-IP コールフローを備えたローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に内部ループバック ダイヤルピアのセットを導入してコール ルーティングを変更します。次のループバックダイヤルピアを設定します。この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。ルーティング タグを削除すると、通話はダイヤルピア グループを使用して発信トランクへルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad 

以下は、設定のフィールドの説明です。


dial-peer voice 10 voip
 description Outbound loop-around leg

VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。詳細については、 ダイヤルピア音声を参照してください。

翻訳プロファイル受信 11

以前に定義した変換プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。詳細については、 destination-pattern (interface)を参照してください。

session protocol sipv2

このダイヤルピアが SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

セッションターゲット IPv4: 192.168.80.14

ループバックするコールターゲットとしてローカル ルータ インターフェイス アドレスを指定します。詳細については、 セッション ターゲット (VoIP ダイヤル ピア)を参照してください。

バインド制御ソースインターフェイス GigabitEthernet0/0/0

ループバックを介して送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

メディアソースインターフェースをバインドする GigabitEthernet0/0/0

ループバックを介して送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

コーデック g711alaw

すべての PSTN 通話に G.711 の使用を強制します。ISDN サービスで使用される圧縮方式に合わせて、a-law または u-law を選択します。

no vad

音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

5

次の通話ルーティング構成を追加します。

  1. ダイヤルピア グループを作成し、ループバックを介して PSTN トランクと Webex トランク間の通話をルーティングします。

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 10
     description Route calls to Loopback
     dial-peer 10

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、 voice-class dpgを参照してください。

  2. ダイヤルピア グループを適用して通話をルーティングします。

    
    dial-peer voice 100
     destination dpg 10
    dial-peer voice 200
     destination dpg 10
    dial-peer voice 11
     destination dpg 100
    dial-peer voice 12
     destination dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    この着信ダイヤルピアに提示された通話の発信処理に使用するダイヤルピア グループ、つまりダイヤルピアを指定します。

これでローカル ゲートウェイの構成は完了です。CUBE 機能を初めて構成する場合は、構成を保存してプラットフォームを再ロードします。

前のセクションの PSTN-Webex Calling 構成は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべての通話は Unified CM 経由でルーティングされます。ポート 5060 の UCM からの通話は PSTN にルーティングされ、ポート 5065 からの通話は Webex Calling にルーティングされます。この呼び出しシナリオを含めるには、次の増分構成を追加できます。

Unified CM で Webex Calling トランクを作成する場合は、SIP トランク セキュリティ プロファイル設定で着信ポートを 5065 に設定してください。これにより、ポート 5065 での受信メッセージが許可され、メッセージをローカル ゲートウェイに送信するときに、VIA ヘッダーにこの値が設定されます。

SIPトランクのセキュリティプロファイル情報を入力します
1

以下の音声クラス URI を設定:

  1. SIP VIA ポートを使用して、Unified CM から Webex への通話を分類します。

    
    voice class uri 300 sip
     pattern :5065
    
  2. ポート経由で SIP を使用して Unified CM から PSTN への通話を分類します。

    
    voice class uri 400 sip
     pattern 192\.168\.80\.6[0-5]:5060
    

    発信元アドレスとポート番号を記述する 1 つ以上のパターンを使用して、UCM から PSTN トランクへの受信メッセージを分類します。必要に応じて、正規表現を使用して一致パターンを定義することもできます。

    上記の例では、正規表現を使用して、192.168.80.60 ~ 65 の範囲の IP アドレスとポート番号 5060 のいずれかを一致させます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE はこれらのレコードを使用して、ターゲット UCM ホストとポートをローカルで決定します。この構成では、DNS システムでレコードを構成する必要はありません。DNS を使用する場合は、これらのローカル構成は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドは、DNS SRV リソース レコードを作成します。各 UCM ホストおよびトランクのレコードを作成します。

IPホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

_sip._udp.pstntocucm.io: SRVリソースレコード名

2: SRVリソースレコードの優先度

1: SRVリソースレコードの重み

5060: このリソースレコード内のターゲットホストに使用するポート番号

ucmsub5.mydomain.com: リソースレコードのターゲットホスト

リソース レコードのターゲット ホスト名を解決するには、ローカル DNS A レコードを作成します。たとえば、次のようなものです。

IPホスト ucmsub5.mydomain.com 192.168.80.65

IPホスト: ローカル IOS XE データベースにレコードを作成します。

ucmsub5.mydomain.com: A レコードのホスト名。

192.168.80.65: ホストの IP アドレス。

UCM 環境と優先コール分配戦略を反映する SRV リソース レコードと A レコードを作成します。

3

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間の通話用のダイヤルピア:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     incoming uri via 300
     voice-class codec 100
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    以下は、設定のフィールドの説明です。

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

    セッションターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルに定義された SRV レコード wxtocucm.io を使用して呼び出しが直接行われます。

    incoming uri via 300

    音声クラス URI 300 を使用して、送信元ポート 5065 を使用する Unified CM からのすべての着信トラフィックをこのダイヤルピアに送信します。詳細については、 受信 URIを参照してください。

    音声クラスコーデック 100

    Unified CM との間の通話のコーデック フィルタ リストを示します。詳細については、 音声クラスコーデックを参照してください。

    バインド制御 source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    バインドメディア source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

  2. Unified CM と PSTN 間の通話用のダイヤルピア:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     incoming uri via 400
     voice-class codec 100 
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    以下は、設定のフィールドの説明です。

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

    タグ 400 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルに定義された SRV レコード pstntocucm.io を使用して通話が転送されます。

    400 経由の URI の受信

    音声クラス URI 400 を使用して、送信元ポート 5060 を使用する指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに送信します。詳細については、 受信 URIを参照してください。

    音声クラスコーデック 100

    Unified CM との間の通話のコーデック フィルタ リストを示します。詳細については、 音声クラスコーデックを参照してください。

    バインド制御 source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    バインドメディア source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

4

次の設定を使用して通話ルーティングを追加します。

  1. ダイヤルピア グループを作成して、Unified CM と Webex Calling 間の通話をルーティングします。Webex Calling に向かう 発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM への発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Unified CM と PSTN 間の通話をルーティングするためのダイヤルピア グループを作成します。PSTNへの発信ダイヤルピア200でDPG 200を定義します。DPG 200 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM への発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 400
     description Route calls to Unified CM PSTN trunk
     dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、 voice-class dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM へ、また Unified CM から Webex への通話をルーティングします。

    
    dial-peer voice 100
     destination dpg 300
    dial-peer voice 300
     destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    この着信ダイヤルピアに提示された通話の発信処理に使用するダイヤルピア グループ、つまりダイヤルピアを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM へ、また Unified CM から PSTN への通話をルーティングします。

    
    dial-peer voice 200
     destination dpg 400
    dial-peer voice 400
     destination dpg 200 

    これでローカル ゲートウェイの構成は完了です。CUBE 機能を初めて構成する場合は、構成を保存してプラットフォームを再ロードします。

診断署名 (DS) は、IOS XE ベースのローカル ゲートウェイで共通に観察される問題を積極的に検出し、イベントのメール、syslog、またはターミナル メッセージ通知を生成します。DS をインストールして診断データの収集を自動化し、収集したデータを Cisco TAC ケースに転送して解決時間を短縮することもできます。

診断署名 (DS) は、問題のトリガー イベントと問題を通知、トラブルシューティング、修正するために取られるアクションに関する情報を含む XML ファイルです。Syslog メッセージ、SNMP イベント、および特定の show コマンド出力の定期的な監視を使用して、問題検出ロジックを定義できます。

アクションタイプには、show command 出力の収集が含まれます。

  • 統合ログファイルの生成

  • HTTPS、SCP、FTP サーバーなどのユーザー指定のネットワークの場所にファイルをアップロードします。

TAC エンジニアは DS ファイルの作成者であり、整合性保護のためにデジタル署名します。各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。診断シグネチャ検索ツール (DSLT) は、さまざまな問題を監視およびトラブルシューティングするための適用可能なシグネチャを見つけるための単一のソースです。

開始する前に:

  • DSLT からダウンロードした DS ファイルは 編集していない。変更するファイルは、整合性チェックエラーのためインストールに失敗します。

  • ローカル ゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル (SMTP) サーバー。

  • メール通知に安全な SMTP サーバーを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以上を実行中か確認してください。

前提条件

IOS XE 17.6.1a 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合は、プロアクティブ通知の送信に使用するセキュア電子メール サーバーを設定します。

    configure terminal 
    call-home  
    mail-server :@ priority 1 secure tls 
    end 

  3. 通知する管理者のメールアドレスを環境変数 ds_email に設定します。

    configure terminal 
    call-home  
    diagnostic-signature 
    environment ds_email  
    end 

以下は、Cisco IOS XE 17.6.1a以降で実行されているローカルゲートウェイがプロアクティブ通知を に送信する設定例を示しています。 tacfaststart@gmail.com Gmailを安全なSMTPサーバーとして使用する場合:

Cisco IOS XE Bengaluru 17.6.x 以降のバージョンを使用することをお勧めします。

call-home  
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls 
diagnostic-signature 
environment ds_email "tacfaststart@gmail.com" 

Cisco IOS XE ソフトウェアで起動するローカル ゲートウェイは OAuth に対応する一般的なウェブベースの Gmail クライアントではないので、特定の Gmail アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. Googleアカウントの管理 に移動 > セキュリティ にアクセスし、 安全性の低いアプリのアクセス 設定をオンにします。

  2. 「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

このDSはSNMP OIDを使用して5秒間CPU使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. SNMP を有効にするには、 show snmp コマンドを使用します。有効にしない場合は、 snmp-server manager コマンドを設定します。

    show snmp 
    %SNMP agent not enabled 
    
    config t 
    snmp-server manager 
    end 
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
    
  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    LocalGateway# copy ftp://username:password@/DS_64224.xml bootflash: 

    次の例では、FTP サーバーからローカル ゲートウェイへのファイルのコピーを示しています。

    copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: 
    Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! 
    [OK - 3571/4096 bytes] 
    3571 bytes copied in 0.064 secs (55797 bytes/sec) 
    
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
  5. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。ステータス列の値が「registered」になっているはずです。

    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
    Diagnostic-signature: enabled 
    Profile: CiscoTAC-1 (status: ACTIVE) 
    Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
    Environment variable: 
    ds_email: username@gmail.com 

    DSes をダウンロード:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-07 22:05:33

    トリガーされると、この署名によって、この署名そのものを含む実行中のすべての DS がアンインストールされます。必要に応じて、DS 64224 を再インストールして、ローカル ゲートウェイでの CPU 使用率の高さを引き続き監視します。

SIP トランク登録のモニタリング

この DS は、60 秒ごとにクラウドにSIP トランクするローカル Webex Calling登録解除をチェックします。登録解除イベントが検出されると、メールとSyslog通知が生成され、登録解除が2回発生すると自動的にアンインストールされます。シグネチャをインストールするには、以下の手順に従ってください。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64117.xml bootflash: 
  3. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64117.xml 
    Load file DS_64117.xml success 
    LocalGateway#  
  4. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

異常な通話切断の監視

このDSは、10分ごとにSNMPポーリングを行い、SIPエラー403、488、503による異常な通話切断を検出します。前回のポーリングからエラーカウントの増分が5以上になった場合、Syslogとメール通知が生成されます。シグネチャをインストールするには、以下の手順に従ってください。

  1. SNMP が有効になっているかどうかを確認するには、 show snmp コマンドを使用します。有効になっていない場合は、 snmp-server manager コマンドを設定します。

    show snmp 
    %SNMP agent not enabled 
     
    
    config t 
    snmp-server manager 
    end 
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
    
  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_65221.xml bootflash:
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
    
  5. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

診断署名をインストールして問題のトラブルシューティングを行う

診断署名 (DS) を使用して、問題を迅速に解決します。Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題の発生を検出、診断データの正しいセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを可能にするための署名を作成しました。診断シグネチャ (DS) により、問題の発生を手動で確認する必要がなくなり、断続的および一時的な問題のトラブルシューティングが大幅に容易になります。

診断署名ルックアップ ツールを使用して、適用可能な署名を見つけ、自己解決するためにインストールすることができます。または、サポート エンゲージメントの一部として、TAC エンジニアが推奨する署名をインストールできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): SYSLOG=1.1.181.1.29.0" syslog を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 追加のDS環境変数 ds_fsurl_prefixを設定します。これは、収集された診断データがアップロードされるCisco TACファイルサーバ(cxd.cisco.com)のパスです。ファイルパス内のユーザー名はケース番号、パスワードはファイルアップロードトークンです。これらのトークンは、次のコマンドで Support Case Manager から取得できます。ファイルアップロードトークンは、必要に応じてSupport Case Managerの Attachments セクションで生成できます。

    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com"  
    end 

    例:

    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、 snmp-server manager コマンドを設定します。

    show snmp 
    %SNMP agent not enabled 
     
     
    config t 
    snmp-server manager 
    end 
  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65095 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    Syslog

    問題の種類

    Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64224.xml bootflash: 
    copy ftp://username:password@/DS_65095.xml bootflash: 
  6. ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。

    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
     
    call-home diagnostic-signature load DS_65095.xml 
    Load file DS_65095.xml success 
    
  7. show call-home diagnostic-signature コマンドを使用して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
    Diagnostic-signature: enabled 
    Profile: CiscoTAC-1 (status: ACTIVE) 
    Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
    Environment variable: 
               ds_email: username@gmail.com 
               ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

    ダウンロードされた DSes:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    00:07:45

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-08

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    登録済み

    2020-11-08

診断署名の実行を確認します

次のコマンドでは、ローカル ゲートウェイがシグニチャ内で定義されたアクションを実行している間、 show call-home diagnostic-signature コマンドの「ステータス」列が「実行中」に変わります。show call-home 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/Max/Deinstall」欄は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義される最大回数、トリガーされたイベントの最大数を検出した後に署名が自身をインストールアンインストールするかどうかを示します。

show call-home diagnostic-signature  
Current diagnostic-signature settings: 
Diagnostic-signature: enabled 
Profile: CiscoTAC-1 (status: ACTIVE) 
Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
Environment variable: 
           ds_email: carunach@cisco.com 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

ダウンロードされた DSes:

DS ID

DS 名

リビジョン

ステータス

最終更新日時(GMT+00:00)

64224

DS_LGW_CPU_MON75

0.0.10

登録済み

2020-11-08 00:07:45

65095

DS_LGW_IEC_Call_spike_threshold

0.0.12

実行中

2020-11-08 00:12:53

コール ホーム診断署名統計を表示する

DS ID

DS 名

トリガー/Max/Deinstall

平均実行時間(秒)

最長実行時間(秒)

64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

診断署名通知メール送信されるコマンドには、問題の種類、デバイスの詳細、ソフトウェア バージョン、実行構成、与えられた問題のトラブルシューティングに関連するコマンド出力の表示など、重要な情報が含まれている必要があります。

診断署名をアンインストールする

トラブルシューティングのために診断署名を使用は、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。署名を手動でアンインストールする場合は、 show call-home diagnostic-signature コマンドの出力から DS ID を取得し、次のコマンドを実行します。

call-home diagnostic-signature deinstall  

例:

call-home diagnostic-signature deinstall 64224 

診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Cisco IOS XE ゲートウェイをより適切に管理するには、Control Hub を介してゲートウェイを登録および管理することをお勧めします。オプションの構成です。登録すると、コントロール ハブの構成検証オプションを使用して、ローカル ゲートウェイの構成を検証し、構成の問題を特定できます。現在、この機能をサポートしているのは登録ベースのトランクのみです。

詳細については、以下を参照してください。

このセクションでは、証明書ベースの相互 TLS (mTLS) SIP トランクを使用して、Cisco Unified Border Element (CUBE) を Webex Calling のローカル ゲートウェイとして設定する方法について説明します。このドキュメントの最初の部分では、単純な PSTN ゲートウェイを構成する方法を説明します。この場合、PSTN からのすべての通話は Webex Calling にルーティングされ、Webex Calling からのすべての通話は PSTN にルーティングされます。次の図は、このソリューションと、それに従う高レベルの通話ルーティング構成を示しています。

この設計では、次の主要な構成が使用されます。

  • 音声クラスのテナント: Used トランク固有の構成を作成します。

  • 音声クラス uri: 着信ダイヤルピアの選択のために SIP メッセージを分類するために使用されます。

  • 着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループを使用して発信ルートを決定します。

  • ダイヤルピアグループ: 転送コール ルーティングに使用される発信ダイヤルピアを定義します。

  • 発信ダイヤルピア: 送信 SIP メッセージを処理し、必要なターゲットにルーティングします。

通話ルーティング from/to 公衆回線 to/from Webex Calling 構成ソリューション

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、次の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling 通話の集中ルーティングと処理を提供します。

ソリューション図では、Unified Communications Manager がすべての PSTN および Webex Calling 通話の集中ルーティングと処理を提供していることが示されています。

このドキュメント全体では、次の図に示すホスト名、IP アドレス、およびインターフェースが使用されます。パブリックまたはプライベート (NAT の背後) アドレス指定のオプションが提供されます。複数の CUBE インスタンス間で負荷分散を行わない限り、SRV DNS レコードはオプションです。

証明書ベースのローカルゲートウェイ構成で使用されるホスト名、IPアドレス、およびインターフェース

このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの構成を完了します。

ベースライン構成

Cisco ルーターを Webex Calling のローカル ゲートウェイとして準備するための最初の手順は、プラットフォームを保護し、接続を確立するベースライン構成を構築することです。

  • すべての証明書ベースのローカル ゲートウェイ展開には、Cisco IOS XE 17.9.1a 以降のバージョンが必要です。Cisco IOS XE 17.12.2 以降が推奨されます。推奨バージョンについては、 Cisco Software Research ページを参照してください。プラットフォームを検索し、 推奨される リリースのいずれかを選択します。

    • ISR4000 シリーズ ルータは、ユニファイド コミュニケーションとセキュリティ テクノロジーのライセンスの両方を使用して設定する必要があります。

    • 音声カードまたは DSP を搭載した Catalyst Edge 8000 シリーズ ルータには、DNA Advantage ライセンスが必要です。音声カードまたは DSP のないルーターには、最低限 DNA Essentials ライセンスが必要です。

    • 大容量の要件の場合は、高セキュリティ (HSEC) ライセンスと追加のスループット権限も必要になる場合があります。

      詳細については、 承認コード を参照してください。

  • ビジネス ポリシーに従ったプラットフォームのベースライン構成を構築します。特に、次の項目を設定して検証します。

    • NTP

    • Acl

    • ユーザー認証とリモートアクセス

    • DNS

    • IP ルーティング

    • IPアドレス

  • Webex Calling へのネットワークでは IPv4 アドレスを使用する必要があります。コントロール ハブで構成されたローカル ゲートウェイの完全修飾ドメイン名 (FQDN) またはサービス レコード (SRV) アドレスは、インターネット上のパブリック IPv4 アドレスに解決される必要があります。

  • Webex 側のローカル ゲートウェイ インターフェイス上のすべての SIP ポートとメディア ポートは、直接または静的 NAT 経由でインターネットからアクセスできる必要があります。それに応じてファイアウォールを更新してください。

  • ローカル ゲートウェイに署名付き証明書をインストールするには、以下の詳細な構成手順に従ってください。

    • Cisco Webex オーディオおよびビデオ プラットフォームへの通話にサポートされているルート証明機関は何ですか? に詳述されているパブリック証明機関 (CA) がデバイス証明書に署名する必要があります。

    • 証明書のサブジェクト共通名 (CN)、またはサブジェクト別名 (SAN) の 1 つは、Control Hub で構成された FQDN と同じである必要があります。たとえば、次のようなものです。

      • 組織のコントロールハブに設定されたトランクに cube1.lgw.com:5061 ローカル ゲートウェイの FQDN として、ルータ証明書の CN または SAN に cube1.lgw.com が含まれている必要があります。

      • 組織のコントロール ハブで構成されたトランクに、トランクから到達可能なローカル ゲートウェイの SRV アドレスとして lgws.lgw.com が含まれている場合、ルータ証明書の CN または SAN には lgws.lgw.com が含まれている必要があります。クライアント アドレスが 解決SRV (CNAME、A レコード、または IP アドレス) のレコードは、SAN ではオプションです。

      • トランクに対して FQDN または SRV のどちらを使用する場合でも、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスには、コントロール ハブで構成された名前を使用する必要があります。

    • 証明書がクライアントとサーバーの使用のために署名されていることを確認します。

  • Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。このバンドルには、Webex プラットフォームの検証に使用される CA ルート証明書が含まれています。

構成

1

有効かつルーティング可能な IP アドレスがすべてのレイヤー 3 インターフェイスに割り当てられていることを確認します。次に例を示します。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240

2

対称暗号化を使用してルーター上の STUN 資格情報を保護します。プライマリ暗号化キーと暗号化タイプを次のように構成します。


key config-key password-encrypt YourPassword
password encryption aes
3

がサポートする 証明機関 (CA) によって署名されたドメインの証明書を使用して暗号化信頼ポイントを作成します。

  1. 次の exec コマンドを使用して RSA キー ペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 証明書署名要求で使用するフィールド値を指定して、証明書のトラストポイントを作成するには、次の設定コマンドを使用します。

    
    crypto pki trustpoint LGW_CERT
     enrollment terminal pem
     fqdn none
     subject-name cn=cube1.lgw.com
     subject-alt-name cube1.lgw.com
     revocation-check none
     rsakeypair lgw-key
     hash sha256 

    証明書フィールドに関する注意事項:

    • FQDN: これは Webex Calling の必須フィールドではありません。この構成を「なし」に設定すると、証明書署名要求にこのフィールドが含まれなくなります。このコマンドを使用して FQDN を含める必要がある場合、ローカル ゲートウェイの操作には影響はありません。

    • 件名: ローカル ゲートウェイからの通話を検証するには、Webex は SIP 連絡先ヘッダーの FQDN を、SBC 証明書の Subject Common Name (CN) 属性または Subject Alternative Name (SAN) フィールドのいずれかに含まれるものと一致させる必要があります。件名フィールドには少なくとも CN 属性が含まれている必要があり、必要に応じて他の属性を含めることもできます。詳細については、 subject-nameを参照してください。

    • 件名の別名: SBC 証明書のサブジェクト別名 (SAN) フィールドには、追加の FQDN のリストを含めることができます。Webex は、証明書の Subject CN 属性が一致しない場合、このリストをチェックして、ローカル ゲートウェイからのメッセージ内の SIP 連絡先ヘッダーを検証します。

    • ハッシュ: 証明書署名要求 (CSR) は SHA256 を使用して署名することをお勧めします。Cisco IOS XE 17.11.1 ではこのアルゴリズムがデフォルトで使用され、以前のリリースでは Hash コマンドが使用されます。

  3. 次の exec コマンドまたは構成コマンドを使用して証明書署名要求 (CSR) を生成し、それを使用してサポートされている CA プロバイダーから署名付き証明書を要求します。

    crypto pki enroll LGW_CERT

4

ホスト証明書を認証するには、中間署名 CA の証明書を提供します。次の exec コマンドまたは設定コマンドを入力します。


crypto pki authenticate LGW_CERT

5

次の exec または構成コマンドを使用して、署名されたホスト証明書をインポートします。


crypto pki import LGW_CERT certificate

6

次の設定コマンドを使用して、TLS1.2 の排他性を有効にし、音声アプリケーションに使用するデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2

7

Webex Calling で使用される IdenTrust Commercial Root CA 1 証明書を含む Cisco ルート CA バンドルをインストールします。 crypto pki trustpool import clean url url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアしてから、新しい証明書バンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の構成を追加します。

ip http client proxy-server yourproxy.com proxy-port 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
1

コントロール ハブ内の既存の場所に CUBE 証明書ベースの PSTN トランクを作成します。詳細については、 「 Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

トランクを作成するときに、トランク情報をメモします。次の図で強調表示されているこれらの詳細は、このガイドの構成手順で使用されます。

CUBE証明書ベースのPSTNトランクが作成される
2

CUBE を Webex Calling ローカル ゲートウェイとして設定するには、次のコマンドを入力します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y
  • 通話料金詐欺を防ぐために、信頼できるアドレス リストには、ローカル ゲートウェイが正当な VoIP 通話を期待するホストとネットワーク エンティティのリストが定義されています。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストにない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に構成されたダイヤルピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを構成するときは、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、 Webex Calling のポート参照情報 を参照してください。また、Unified Communications Manager サーバー (使用されている場合) と PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 不正通話を防止するために IP アドレス信頼リストを使用する方法の詳細については、 IP アドレス信頼リストを参照してください。

モード境界要素

プラットフォーム上で Cisco Unified Border Element (CUBE) 機能を有効にします。

allow-connections sip to sip

CUBE の基本的な SIP バックツーバック ユーザー エージェント機能を有効にします。詳細については、 接続を許可するを参照してください。

デフォルトでは、T.38 FAX トランスポートは有効になっています。詳細については、 FAXプロトコルT38 (音声サービス)を参照してください。

スタン

STUN (NAT を介した UDP のセッション トラバーサル) をグローバルに有効にします。

これらのグローバル stun コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。

  • ローカル ゲートウェイの STUN バインディング機能により、ローカルで生成された STUN 要求をネゴシエートされたメディア パス経由で送信できるようになります。これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、 stun flowdata agent-idおよび stun flowdata shared-secretを参照してください。

非対称ペイロードフル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを構成します。このコマンドの詳細については、 非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つのではなく、初期 INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、 early-offerを参照してください。

SIPプロファイル受信

CUBE が SIP プロファイルを使用して、受信時にメッセージを変更できるようにします。プロファイルはダイヤルピアまたはテナントを通じて適用されます。

3

voice class codec 100 を設定し、すべてのトランクに対して G.711 コーデックのみを許可します。このシンプルなアプローチは、ほとんどの展開に適しています。必要に応じて、発信側システムと着信側システムの両方でサポートされている追加のコーデック タイプをリストに追加します。

DSP モジュールを使用した トランスコーディング を含む、より複雑なソリューションもサポートされていますが、このガイドには含まれていません。


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラスコーデック 100

SIP トランク通話に優先コーデックのみを許可するために使用されます。詳細については、 音声クラスコーデックを参照してください。

4

Webex Callingトランク上でICEを有効にするには、 voice class stun-usage 100 を設定します。(この手順は Webex for Government には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

スタン使用アイスライト

可能な限りメディア最適化を可能にするために、すべての Webex Calling 対応ダイヤルピアに対して ICE-Lite を有効にするために使用されます。詳細については、 voice class stun usage および stun usage ice liteを参照してください。

stun usage firewall-traversal flowdataコマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。

メディアの最適化は可能な限りネゴシエートされます。通話に録音などのクラウド メディア サービスが必要な場合は、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。(この手順は Webex for Government には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーおよびアンサーメッセージのSDPでCUBEが提供する唯一のSRTP暗号スイートとしてSHA1_80を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、 voice class srtp-cryptoを参照してください。

6

FIPS 準拠の GCM 暗号を設定します (この手順は Webex for Government にのみ適用されます)


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。Webex for Government の Local Gateway に GCM 暗号を設定することが必須です。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへの通話を一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

以下は、設定のフィールドの説明です。

音声クラス URI 100 SIP

着信 SIP 招待を着信トランク ダイヤルピアに一致させるパターンを定義します。このパターンを入力するときは、トランクに対して Control Hub で設定されたトランク FQDN または SRV を使用します。

証明書ベースのトランクを設定する場合は、ローカル ゲートウェイで SRV ベースの Webex Calling エッジ アドレスを使用します。

8

SIP メッセージ操作プロファイルを構成します。ゲートウェイがパブリック IP アドレスで構成されている場合は、次のようにプロファイルを構成するか、NAT を使用している場合は次の手順に進みます。この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN です。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 

以下は、設定のフィールドの説明です。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、コントロール ハブのトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスターに使用される SRV 名のいずれかになります。

9

ゲートウェイが静的 NAT の背後にあるプライベート IP アドレスで構成されている場合は、次のように着信および発信 SIP プロファイルを構成します。この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN、"10.80.13.12" は Webex Calling 側のインターフェイス IP アドレス、"192.65.79.20" は NAT パブリック IP アドレスです。

Webex Calling への発信メッセージ用の SIP プロファイル

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、コントロール ハブのトランクに対してプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスターに使用される SRV 名のいずれかになります。

ルール30から81

プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの着信メッセージの SIP プロファイル

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

ルール10~80

パブリック アドレス参照を設定されたプライベート アドレスに変換し、CUBE が Webex からのメッセージを処理できるようにします。

詳細については、 voice class sip-profilesを参照してください。

米国またはカナダの PSTN プロバイダーは、 Webex Calling でのスパムまたは詐欺通話の表示 の記事に記載されている追加の構成により、スパムおよび詐欺通話に対する発信者 ID 検証を提供できます。

10

ヘッダー変更プロファイルを使用して SIP オプション キープアライブを構成します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "

以下は、設定のフィールドの説明です。

音声クラス SIP オプション キープアライブ 100

キープアライブ プロファイルを設定し、音声クラス設定モードに入ります。エンドポイントへのハートビート接続が UP または Down 状態のときに、SIP Out of Dialog Options Ping がダイヤル ターゲットに送信される時間 (秒単位) を設定できます。

このキープアライブ プロファイルは、Webex に対して設定されたダイヤルピアからトリガーされます。

連絡先ヘッダーに SBC 完全修飾ドメイン名が含まれていることを確認するには、SIP プロファイル 115 が使用されます。ルール 30、40、および 50 は、SBC が静的 NAT の背後に設定されている場合にのみ必要です。

この例では、cube1.lgw.com はローカル ゲートウェイ用に選択された FQDN であり、静的 NAT が使用されている場合、「10.80.13.12」は Webex Calling への SBC インターフェイス IP アドレスであり、「192.65.79.20」は NAT パブリック IP アドレスです。

11

Webex Calling トランクを設定します。

  1. Webex Calling トランクに特に必要な構成を定義およびグループ化するには、 voice class tenant 100 を作成します。このテナントに関連付けられたダイヤルピアは、後でこれらの構成を継承します。

    次の例では、このガイドの目的に合わせて手順 1 で示した値 (太字で表示) を使用しています。これらを設定内のトランクの値に置き換えます。

    
    voice class tenant 100
     no remote-party-id
     sip-server dns:us25.sipconnect.bcld.webex.com
     srtp-crypto 100
     localhost dns:cube1.lgw.com
     session transport tcp tls
     no session refresh
     error-passthru
     rel1xx disable
     asserted-id pai
     bind control source-interface GigabitEthernet0/0/1
     bind media source-interface GigabitEthernet0/0/1
     no pass-thru content custom-sdp
     sip-profiles 100 
     sip-profiles 110 inbound
     privacy-policy passthru
    !

    以下は、設定のフィールドの説明です。

    音声クラステナント 100

    独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定するには、テナントを使用することをお勧めします。ここで、テナントに関連付けられた tls-profile には、新しい接続を受け入れたり作成したりするために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。詳細については、 音声クラステナントを参照してください。

    no remote-party-id

    Webex Calling は PAI をサポートしており、これは asserted-id pai コマンドを使用して有効化されるため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。詳細については、 remote-party-idを参照してください。

    SIPサーバーのDNS: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバーを構成します。トランクを作成したときにコントロールハブで提供されたEdgeプロキシSRVアドレスを使用します

    srtp-crypto 100

    SRTP コール レッグ (接続) の優先暗号スイートを設定します (手順 5 で指定)。詳細については、 voice class srtp-cryptoを参照してください。

    ローカルホスト DNS: cube1.lgw.com

    送信メッセージの From、Call-ID、および Remote-Party-ID ヘッダー内の物理 IP アドレスを、指定された FQDN に置き換えるように CUBE を設定します。ここでのトランクには、コントロール ハブで設定されたトランク FQDN または SRV を使用します。

    session transport tcp tls

    関連するダイヤルピアのトランスポートを TLS に設定します。詳細については、 session-transportを参照してください。

    セッション更新なし

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、 セッションの更新を参照してください。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、 error-passthruを参照してください。

    rel1xx 無効化

    Webex Calling トランクの信頼性の高い暫定応答の使用を無効にします。詳細については、 rel1xxを参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、Webex Calling トランクでこれがどのように使用されるかを制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE に P-Asserted-Identity (PAI) ヘッダーが含まれます。

    このコマンドが設定されている場合、PAIヘッダーの発信者情報が発信元と発信者情報に使用されます。 PAI/Remote-Party-ID ヘッダー。

    このコマンドが設定されていない場合、Fromヘッダーの発信者情報が、発信Fromと PAI/Remote-Party-ID ヘッダー。

    詳細については、 asserted-idを参照してください。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージの送信元インターフェイスと関連 IP アドレスを設定します。詳細については、 bindを参照してください。

    メディアソースインターフェースをバインドする GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスと関連 IP アドレスを設定します。詳細については、 bindを参照してください。

    音声クラス SIP プロファイル 100

    送信メッセージに使用するヘッダー変更プロファイル (パブリック IP または NAT アドレス指定) を適用します。詳細については、 voice-class sip プロファイルを参照してください。

    音声クラス SIP プロファイル 110 着信

    NAT の背後にある LGW 展開の場合のみ: 受信メッセージに使用するヘッダー変更プロファイルを適用します。詳細については、voice-class sip プロファイルを参照してください。

    プライバシーポリシー パススルー

    受信したメッセージから次のコール レッグにプライバシー ヘッダーを透過的に渡すように CUBE を設定します。詳細については、 プライバシーポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     incoming uri request 100
     voice-class codec 100
     voice-class stun-usage 100
     voice-class sip tenant 100
     voice-class sip options-keepalive profile 100
     dtmf-relay rtp-nte 
     srtp
     no vad
    

    以下は、設定のフィールドの説明です。

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling

    タグ 100 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を指定します。詳細については、 ダイヤルピア音声を参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。詳細については、 destination-pattern (interface)を参照してください。

    session protocol sipv2

    このダイヤルピアが SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバーが継承され、このダイヤル ピアからの通話の宛先として使用されることを示します。

    受信URIリクエスト 100

    INVITE REQUEST ヘッダー URI を使用して、このダイヤルピアへの着信コールを一致させるために使用される音声クラスを指定します。詳細については、 受信 URIを参照してください。

    音声クラスコーデック 100

    Webex Calling との間の通話のコーデック フィルター リストを示します。詳細については、 音声クラスコーデックを参照してください。

    ボイスクラス スタン使用率 100

    ローカル ゲートウェイからローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。STUN パケットは、メディア トラフィック用のファイアウォール ピンホールを開き、メディアの最適化のための有効なパスを検出するのに役立ちます。

    音声クラス SIP テナント 100

    ダイヤルピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータはダイヤルピア レベルで上書きされる場合があります。詳細については、 voice-class sip tenantを参照してください。

    音声クラス SIP オプション キープアライブ プロファイル 100

    このコマンドは、特定のプロファイル (100) を使用して SIP サーバーまたはエンドポイントのグループの可用性を監視します。

    srtp

    コールレグの SRTP を有効にする。

上記で Webex Calling へのトランクを構築したら、次の設定を使用して SIP ベースの PSTN プロバイダーへの暗号化されていないトランクを作成します。

サービス プロバイダーが安全な PSTN トランクを提供している場合は、Webex Calling トランクについて上記で説明したのと同様の構成に従うことができます。CUBE は安全な通話ルーティングをサポートします。

TDMを使用している場合 / ISDN PSTN トランクの場合は、次のセクション TDM PSTN トランクを使用してローカル ゲートウェイを構成するに進んでください。

Cisco TDM-SIP ゲートウェイで PSTN コール レッグ用の TDM インターフェイスを設定するには、 ISDN PRI の設定を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス URI を構成します。


voice class uri 200 sip
  host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス URI 200 SIP

着信 SIP 招待を着信トランク ダイヤルピアに一致させるパターンを定義します。このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、 voice class uriを参照してください。

2

次の IP PSTN ダイヤルピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

以下は、設定のフィールドの説明です。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ 200 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。詳細については、 ダイヤルピア音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。詳細については、 destination-pattern (interface)を参照してください。

session protocol sipv2

このダイヤルピアが SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

セッションターゲット IPv4: 192.168.80.13

PSTN プロバイダーに送信される通話のターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名のいずれかになります。詳細については、 セッション ターゲット (VoIP ダイヤル ピア)を参照してください。

200 経由の URI の受信

INVITE VIA ヘッダー URI を使用して、このダイヤルピアへの着信コールを一致させるために使用される音声クラスを指定します。詳細については、 受信 URLを参照してください。

音声クラス SIP アサート ID PAI

(オプション) P-Asserted-Identity ヘッダー処理をオンにし、PSTN トランクでこれがどのように使用されるかを制御します。このコマンドを使用すると、着信ダイヤルピアから提供された発信側 ID が、発信 From ヘッダーと P-Asserted-Identity ヘッダーに使用されます。このコマンドを使用しない場合、着信ダイヤルピアから提供された発信側 ID が、発信 From ヘッダーと Remote-Party-ID ヘッダーに使用されます。詳細については、 voice-class sip asserted-idを参照してください。

バインド制御ソースインターフェイス GigabitEthernet0/0/0

PSTN に送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

メディアソースインターフェースをバインドする GigabitEthernet0/0/0

PSTN に送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

音声クラスコーデック 100

共通コーデックフィルタリスト 100を使用するようにダイヤルピアを設定します。詳細については、 voice-class codecを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

3

Webex Calling と PSTN 間の通話のみをルーティングするようにローカル ゲートウェイを設定する場合は、次の通話ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを構成する場合は、次のセクションに進んでください。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN に通話をルーティングします。Webex Calling への発信ダイヤルピア 100 を使用して DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN への発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
    voice class dpg 100 
     description Route calls to Webex Calling 
     dial-peer 100 
    voice class dpg 200 
     description Route calls to PSTN 
     dial-peer 200

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、 voice-class dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN へ、また PSTN から Webex への通話をルーティングします。

    
    dial-peer voice 100
     destination dpg 200
    dial-peer voice 200
     destination dpg 100 

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    この着信ダイヤルピアに提示された通話の発信処理に使用するダイヤルピア グループ、つまりダイヤルピアを指定します。

    これでローカル ゲートウェイの構成は完了です。CUBE 機能を初めて構成する場合は、構成を保存してプラットフォームを再ロードします。

Webex Calling へのトランクを構築したら、次の設定を使用して、ループバック コール ルーティングを備えた PSTN サービス用の TDM トランクを作成し、Webex コール レッグでのメディア最適化を可能にします。

IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア (手順 2 および 3 を参照) を使用します。

1

ループバック ダイヤルピア設定では、ダイヤルピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN 間でコールが正しく渡されるようにします。コール ルーティング タグを追加および削除するために使用される次の変換ルールを構成します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12 

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。10 進数を超える数字 (「A」) は、トラブルシューティングを明確にするために使用されます。

この設定では、translation-profile 100 によって追加されたタグは、Webex Calling からの通話をループバック ダイヤルピア経由で PSTN に誘導するために使用されます。同様に、translation-profile 200 によって追加されたタグは、PSTN からの通話を Webex Calling に誘導するために使用されます。翻訳プロファイル 11 と 12 は、通話をそれぞれ Webex トランクと PSTN トランクに配信する前にこれらのタグを削除します。

この例では、Webex Callingからの着信番号が次のように表示されることを前提としています。 +E.164 形式。ルール100は先頭の + 有効な着信番号を維持するため。ルール 12 では、タグを削除するときに国内または国際ルーティング番号を追加します。ローカルの ISDN 国内ダイヤル プランに適した数字を使用します。

Webex Calling が国別形式で番号を表示する場合は、ルール 100 と 12 を調整して、ルーティング タグをそれぞれ追加および削除するだけです。

詳細については、 voice translation-profile および voice translation-ruleを参照してください。

2

使用するトランク タイプとプロトコルに応じて、TDM 音声インターフェイス ポートを構成します。詳細については、 ISDN PRI の設定を参照してください。たとえば、デバイスの NIM スロット 2 にインストールされているプライマリ レート ISDN インターフェイスの基本構成には、次のようなものがあります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31 
3

次の TDM PSTN ダイヤルピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

以下は、設定のフィールドの説明です。


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 200 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。詳細については、 ダイヤルピア音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。詳細については、 destination-pattern (interface)を参照してください。

翻訳プロファイル受信 200

着信番号にコール ルーティング タグを追加する変換プロファイルを割り当てます。

直通ダイヤル

セカンダリダイヤルトーンを提供せずに通話をルーティングします。詳細については、 direct-inward-dialを参照してください。

ポート 0/2/0:15

このダイヤルピアに関連付けられた物理音声ポート。

4

TDM-IP コールフローを備えたローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に内部ループバック ダイヤルピアのセットを導入してコール ルーティングを変更します。次のループバックダイヤルピアを設定します。この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。ルーティング タグを削除すると、通話はダイヤルピア グループを使用して発信トランクへルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad 

以下は、設定のフィールドの説明です。


dial-peer voice 10 voip
 description Outbound loop-around leg

VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。詳細については、 ダイヤルピア音声を参照してください。

翻訳プロファイル受信 11

以前に定義した変換プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。詳細については、 destination-pattern (interface)を参照してください。

session protocol sipv2

このダイヤルピアが SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

セッションターゲット IPv4: 192.168.80.14

ループバックするコールターゲットとしてローカル ルータ インターフェイス アドレスを指定します。詳細については、 セッション ターゲット (VoIP ダイヤル ピア)を参照してください。

バインド制御ソースインターフェイス GigabitEthernet0/0/0

ループバックを介して送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

メディアソースインターフェースをバインドする GigabitEthernet0/0/0

ループバックを介して送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

コーデック g711alaw

すべての PSTN 通話に G.711 の使用を強制します。ISDN サービスで使用される圧縮方式に合わせて、a-law または u-law を選択します。

no vad

音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

5

次の通話ルーティング構成を追加します。

  1. ダイヤルピア グループを作成し、ループバックを介して PSTN トランクと Webex トランク間の通話をルーティングします。

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 10
     description Route calls to Loopback
     dial-peer 10

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、 voice-class dpgを参照してください。

  2. ダイヤルピア グループを適用して通話をルーティングします。

    
    dial-peer voice 100
     destination dpg 10
    dial-peer voice 200
     destination dpg 10
    dial-peer voice 11
     destination dpg 100
    dial-peer voice 12
     destination dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    この着信ダイヤルピアに提示された通話の発信処理に使用するダイヤルピア グループ、つまりダイヤルピアを指定します。

これでローカル ゲートウェイの構成は完了です。CUBE 機能を初めて構成する場合は、構成を保存してプラットフォームを再ロードします。

前のセクションの PSTN-Webex Calling 構成は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべての通話は Unified CM 経由でルーティングされます。ポート 5060 の UCM からの通話は PSTN にルーティングされ、ポート 5065 からの通話は Webex Calling にルーティングされます。この呼び出しシナリオを含めるには、次の増分構成を追加できます。

1

以下の音声クラス URI を設定:

  1. SIP VIA ポートを使用して、Unified CM から Webex への通話を分類します。

    
    voice class uri 300 sip
     pattern :5065
    
  2. ポート経由で SIP を使用して Unified CM から PSTN への通話を分類します。

    
    voice class uri 400 sip
     pattern 192\.168\.80\.6[0-5]:5060
    

    発信元アドレスとポート番号を記述する 1 つ以上のパターンを使用して、UCM から PSTN トランクへの受信メッセージを分類します。必要に応じて、正規表現を使用して一致パターンを定義することもできます。

    上記の例では、正規表現を使用して、192.168.80.60 ~ 65 の範囲の IP アドレスとポート番号 5060 のいずれかを一致させます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE はこれらのレコードを使用して、ターゲット UCM ホストとポートをローカルで決定します。この構成では、DNS システムでレコードを構成する必要はありません。DNS を使用する場合は、これらのローカル構成は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドは、DNS SRV リソース レコードを作成します。各 UCM ホストおよびトランクのレコードを作成します。

IPホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

_sip._udp.pstntocucm.io: SRVリソースレコード名

2: SRVリソースレコードの優先度

1: SRVリソースレコードの重み

5060: このリソースレコード内のターゲットホストに使用するポート番号

ucmsub5.mydomain.com: リソースレコードのターゲットホスト

リソース レコードのターゲット ホスト名を解決するには、ローカル DNS A レコードを作成します。たとえば、次のようなものです。

IPホスト ucmsub5.mydomain.com 192.168.80.65

IPホスト: ローカル IOS XE データベースにレコードを作成します。

ucmsub5.mydomain.com: A レコードのホスト名。

192.168.80.65: ホストの IP アドレス。

UCM 環境と優先コール分配戦略を反映する SRV リソース レコードと A レコードを作成します。

3

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間の通話用のダイヤルピア:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     incoming uri via 300
     voice-class codec 100
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    以下は、設定のフィールドの説明です。

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を指定します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

    セッションターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルに定義された SRV レコード wxtocucm.io を使用して呼び出しが直接行われます。

    incoming uri via 300

    音声クラス URI 300 を使用して、送信元ポート 5065 を使用する Unified CM からのすべての着信トラフィックをこのダイヤルピアに送信します。詳細については、 受信 URIを参照してください。

    音声クラスコーデック 100

    Unified CM との間の通話のコーデック フィルタ リストを示します。詳細については、 音声クラスコーデックを参照してください。

    バインド制御 source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    バインドメディア source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

  2. Unified CM と PSTN 間の通話用のダイヤルピア:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     incoming uri via 400
     voice-class codec 100 
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    以下は、設定のフィールドの説明です。

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

    タグ 400 を持つ VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするためのわかりやすい説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミーの宛先パターンが必要です。この場合、有効な宛先パターンをどれでも使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理することを指定します。詳細については、 セッション プロトコル (ダイヤル ピア)を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルに定義された SRV レコード pstntocucm.io を使用して通話が転送されます。

    400 経由の URI の受信

    音声クラス URI 400 を使用して、送信元ポート 5060 を使用する指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに送信します。詳細については、 受信 URIを参照してください。

    音声クラスコーデック 100

    Unified CM との間の通話のコーデック フィルタ リストを示します。詳細については、 音声クラスコーデックを参照してください。

    バインド制御 source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    バインドメディア source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアの送信元インターフェイスと関連する IP アドレスを設定します。詳細については、 bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、 DTMFリレー(Voice over IP)を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、 vad (ダイヤルピア)を参照してください。

4

次の設定を使用して通話ルーティングを追加します。

  1. ダイヤルピア グループを作成して、Unified CM と Webex Calling 間の通話をルーティングします。Webex Calling に向かう 発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM への発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Unified CM と PSTN 間の通話をルーティングするためのダイヤルピア グループを作成します。PSTNへの発信ダイヤルピア200でDPG 200を定義します。DPG 200 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM への発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 400
     description Route calls to Unified CM PSTN trunk
     dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、 voice-class dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM へ、また Unified CM から Webex への通話をルーティングします。

    
    dial-peer voice 100
     destination dpg 300
    dial-peer voice 300
     destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    この着信ダイヤルピアに提示された通話の発信処理に使用するダイヤルピア グループ、つまりダイヤルピアを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM へ、また Unified CM から PSTN への通話をルーティングします。

    
    dial-peer voice 200
     destination dpg 400
    dial-peer voice 400
     destination dpg 200 

    これでローカル ゲートウェイの構成は完了です。CUBE 機能を初めて構成する場合は、構成を保存してプラットフォームを再ロードします。

診断署名 (DS) は、Cisco IOS XE ベースのローカル ゲートウェイで共通に観察される問題を事前に検出し、イベントのメール、syslog、またはターミナル メッセージ通知を生成します。さらに、DS をインストールして診断データ収集を自動化し、収集したデータを Cisco TAC ケースに転送して解決時間を短縮することもできます。

診断署名 (DS) は、問題のトリガー イベントと問題を通知、トラブルシューティング、修正するためのアクションに関する情報を含む XML ファイルです。syslog メッセージ、SNMP イベント、および特定のコマンド出力の定期的な監視を使用して、問題の検出ロジックを定義します。アクションタイプには以下が含まれます。

  • show command 出力を収集中

  • 統合ログファイルの生成

  • HTTPS、SCP、FTP サーバーなどのネットワークロケーションをユーザーにアップロードする

TAC エンジニアは DS ファイルを作成し、整合性保護のためにデジタル署名します。各 DS ファイルには、システムによって割り当てられた固有の数字の ID があります。診断シグネチャ検索ツール (DSLT) は、さまざまな問題を監視およびトラブルシューティングするための適用可能なシグネチャを見つけるための単一のソースです。

開始する前に:

  • DSLT からダウンロードした DS ファイルは 編集していない。変更するファイルは、整合性チェックエラーのためインストールに失敗します。

  • ローカル ゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル (SMTP) サーバー。

  • メール通知に安全な SMTP サーバーを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以上を実行中か確認してください。

前提条件

IOS XE 17.6.1 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以上を実行している場合に、プロアクティブ通知を送信するために使用する安全なメール サーバーを構成します。

    
    configure terminal 
    call-home  
    mail-server :@ priority 1 secure tls 
    end 

  3. 通知する管理者 ds_email のメールアドレスを使用して、環境変数を設定します。

    
    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email  
    end 

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して SNMP を有効に設定し、 snmp を表示します。SNMP が有効になっていない場合は、 snmp-server manager コマンドを設定します。

    
    show snmp 
    %SNMP agent not enabled  
    
    config t 
    snmp-server manager 
    end  
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
    
  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    copy ftp://username:password@/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V エッジ ソフトウェア

    製品

    Webex CallingソリューションのCUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高 CPU 使用率

    診断シグネチャ検索ツールから DS 64224 をダウンロードする
  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    copy ftp://username:password@/DS_64224.xml bootflash:

    次の例では、FTP サーバーからローカル ゲートウェイへのファイルのコピーを示しています。

    copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: 
    Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! 
    [OK - 3571/4096 bytes] 
    3571 bytes copied in 0.064 secs (55797 bytes/sec) 
    
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success  
  5. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

    
    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
     Diagnostic-signature: enabled 
     Profile: CiscoTAC-1 (status: ACTIVE) 
     Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
     Environment variable: 
               ds_email: username@gmail.com 

    DSes をダウンロード:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-07 22:05:33

    トリガーされると、この署名によって、この署名そのものを含む実行中のすべての DS がアンインストールされます。必要な場合、DS 64224 を再インストールして、ローカル ゲートウェイで高い CPU 使用率の監視を続行してください。

異常な通話切断の監視

このDSは、10分ごとにSNMPポーリングを行い、SIPエラー403、488、503による異常な通話切断を検出します。前回のポーリングからエラーカウントの増分が5以上になった場合、Syslogとメール通知が生成されます。シグネチャをインストールするには、以下の手順に従ってください。

  1. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMPが有効になっていない場合は、 snmp-server manager コマンドを設定します。

    show snmp 
    %SNMP agent not enabled  
    
    config t 
    snmp-server manager 
    end  
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V エッジ ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_65221.xml bootflash:
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
  5. 署名が正常にインストールされたことを確認するには、コマンド show call-home diagnostic-signature を使用します。ステータス列の値が「registered」になっているはずです。

診断署名をインストールして問題のトラブルシューティングを行う

診断署名 (DS) を使用して、問題を迅速に解決できます。Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題の発生を検出、診断データの正しいセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを可能にするための署名を作成しました。これにより、問題の発生を手動で確認する必要がなくなり、断続的、および一時的な問題のトラブルシューティングがはるかに容易になります。

診断 署名ルックアップ ツールを使用して、適用可能な署名を見つけ、与えられた問題を解決するためにインストールするか、サポート エンゲージメントの一部として、TAC エンジニアが推奨する署名をインストールできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): SYSLOG=1.1.181.1.29.0" syslog を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 診断データをアップロードするためのCisco TACファイルサーバパス(cxd.cisco.com)を、別のDS環境変数 ds_fsurl_prefixに設定してください。ファイルパス内のユーザー名はケース番号、パスワードはファイルアップロードトークンです。このトークンは Support Case Manager から取得できます(以下参照)。ファイルアップロードトークンは、必要に応じてSupport Case Managerの Attachments セクションで生成できます。

    サポートケースマネージャーの添付ファイルセクションで生成されたファイルアップロードトークン
    
    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com"  
    end 

    例:

    
    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMPが有効になっていない場合は、 snmp-server manager コマンドを設定します。

    
    show snmp 
    %SNMP agent not enabled 
     
    config t 
    snmp-server manager 
    end 
  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V エッジ ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65095 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V エッジ ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    Syslog

    問題の種類

    Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    
    copy ftp://username:password@/DS_64224.xml bootflash: 
    copy ftp://username:password@/DS_65095.xml bootflash: 
  6. ローカル ゲートウェイに、高 CPU 監視 DS 64224 をインストールし、次に DS 65095 XML ファイルをインストールします。

    
    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
    call-home diagnostic-signature load DS_65095.xml 
    Load file DS_65095.xml success 
    
  7. show call-home diagnostic-signature を使用して、署名が正常にインストールされていることを確認します。ステータス列の値が「registered」になっているはずです。

    
    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
     Diagnostic-signature: enabled 
     Profile: CiscoTAC-1 (status: ACTIVE) 
     Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
     Environment variable: 
               ds_email: username@gmail.com 
               ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

    ダウンロードされた DSes:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    00:07:45

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-08:00:07:45

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    登録済み

    2020-11-08:00:12:53

診断署名の実行を確認します

次のコマンド で、ローカル ゲートウェイが署名内で定義されたアクションを実行する間、コマンドの「ステータス」列は「実行中」に変更されます。show-home 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/Max/Deinstall」欄は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義される最大回数、トリガーされたイベントの最大数を検出した後に署名が自身をインストールアンインストールするかどうかを示します。

show call-home diagnostic-signature  
Current diagnostic-signature settings: 
 Diagnostic-signature: enabled 
 Profile: CiscoTAC-1 (status: ACTIVE) 
 Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
 Environment variable: 
           ds_email: carunach@cisco.com 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

ダウンロードされた DSes:

DS ID

DS 名

リビジョン

ステータス

最終更新日時(GMT+00:00)

64224

DS_LGW_CPU_MON75

0.0.10

登録済み

2020-11-08 00:07:45

65095

DS_LGW_IEC_Call_spike_threshold

0.0.12

実行中

2020-11-08 00:12:53

コール ホーム診断署名統計を表示する

DS ID

DS 名

トリガー/Max/Deinstall

平均実行時間(秒)

最長実行時間(秒)

64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

診断署名通知メール送信されるレポートには、問題の種類、デバイスの詳細、ソフトウェア バージョン、コンフィギュレーションの実行、および与えられた問題のトラブルシューティングに関連するコマンド出力の表示などの重要な情報が含されます。

診断シグネチャ実行中に送信される通知メール

診断署名をアンインストールする

トラブルシューティングのために診断署名を使用すると、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。署名を手動でアンインストールする場合、show call-home diagnostic-signature の出力から DS ID を取得し、以下のコマンドを実行します。

call-home diagnostic-signature deinstall  

例:

call-home diagnostic-signature deinstall 64224 

診断署名ルックアップ ツールに、展開で見られる問題に基づいて、定期的に新しい署名が追加されます。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。