ローカル ゲートウェイ構成タスク フロー

ローカル ゲートウェイを構成するためのオプションが 2 つあります。 Webex Callingトランク:

  • 登録ベースのトランク

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

下のいずれかでタスクフローを使用し、登録ベースのローカル ゲートウェイまたは証明書ベースのローカル ゲートウェイローカル ゲートウェイの設定Webex Calling trunk。 さまざまなトランクタイプの詳細については、「ローカル ゲートウェイの使い方」を参照してください。 コマンドライン インターフェイス(CLI)を使用して、ローカル ゲートウェイ自体で次の手順を実行します。 セッション開始プロトコル (SIP)とトランスポート レイヤ セキュリティ (TLS) トランスポートを使用してトランクのセキュリティを確保し、 Secure Real-time Protocol (SRTP) を使用して、ローカル ゲートウェイとWebex Callingを選択します。

始める前に

  • プレミスベースの公衆交換電話網 (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解します。 Webex Callingを選択します。 参照先Webex Callingに対するCiscoの推奨アーキテクチャをご覧ください。

  • この記事では、既存の音声構成がない専用のローカル ゲートウェイプラットフォームが設置されていることを前提としています。 既存の PSTN ゲートウェイまたはローカル ゲートウェイ エンタープライズ展開を変更して、 Webex Callingを選択し、構成に注意を払ってください。 変更を行うため、既存のコール フローと機能を中断しないようにしてください。

  • Control Hub でトランクを作成し、その場所に割り当てます。 参照先Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するをご覧ください。


 
この手順には、個々のコマンド オプションの詳細が記載されているコマンド リファレンス ドキュメントへのリンクが含まれています。 すべてのコマンド リファレンス リンクは、 Webexマネージド ゲートウェイ コマンド リファレンス特に断らない限り (その場合、コマンドリンクはCisco IOS音声コマンド リファレンス) を選択してください。 これらのガイドはすべて、Cisco Unified Border Element コマンド リファレンスからアクセスできます。

サードパーティ SBC の詳細については、各製品参照ドキュメントを参照してください。


 

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

始める前に

  • 構成する次のベースラインプラットフォーム構成が、組織のポリシーと手順に従ってセットアップいることを確認してください。

    • NTP

    • ACL

    • パスワードの有効化

    • プライマリパスワード

    • IPルーティング

    • IPアドレスなど

  • すべてのローカル ゲートウェイの展開については、 Cisco IOS XE 16.12 または IOS-XE 17.3 のサポートされている最小リリースが必要です。


 

登録ベースのローカル ゲートウェイをサポートしているのは CUBE のみです。サードパーティ製の他の SBC はサポートされていません。

1

すべてのレイヤー 3 インターフェイスに有効でルーティング可能なIPアドレスを割り当てたことを確認します。

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
ip address 192.168.43.197 255.255.255.0
2

資格情報と共有秘密で使用する前に、次のコマンドを使用してパスワードのプライマリキーを事前に構成します。 AES cipher およびユーザ定義のプライマリキーを使用して Type 6 のパスワードを暗号化します。

conf t
key config-key password-encrypt Password123
password encryption aes
3

IPネーム サーバを設定してDNSルックアップと ping を有効にし、サーバが到達可能であることを確認します。 ローカル ゲートウェイは、 DNSを使用してWebex Callingプロキシアドレスを解決します。

conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ip name-server 8.8.8.8
end
4

TLS 1.2 排他性とデフォルトのプレースホルダー トラストポイントを有効にします。

  1. プレースホルダー PKI トラストポイントを作成して、それをサンプル TPを選択します。

  2. デフォルトのシグナリング トラストポイントとしてトラストポイントを割り当てます。 sip uaを選択します。


     

    次を確認してください: Cn-san-validate サーバ設定したアウトバウンドプロキシが正常に動作した場合にのみ、ローカル ゲートウェイ接続を確立します。テナント 200 (後で説明) サーバーから受信する CN-SAN リストと一致します。

    TLSの暗号化トラストポイントが機能するように設定する必要があります。 接続にはローカルクライアント証明書(例、mTLS) のセットアップは必要ありませんが。

  3. v1.2 を排他的に有効にして、 TLS v1.0 と v1.1 を無効にします。

  4. tcp-retry カウントを 1000 (5 ミリ秒の倍数 = 5 秒) に設定します。

  5. タイマー接続を設定してTLSを確立<wait-timer in="" sec="">を選択します。 範囲は 5 ~ 20 秒で、デフォルトは 20 秒です。 ( TLSは次に利用可能なWebex Calling SBC にアクセスします。 CLI を使用すると、管理者はネットワーク条件に対応し、Access SBC の接続障害をより早く検出できるように値を変更することができます。


     

    Cisco IOS XE 17.3.2 以降のバージョンが適用されます。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
crypto pki trustpoint sampleTP
revocation-check crl
exit

sip-ua
crypto signaling default trustpoint sampleTP cn-san-validate server
transport tcp tls v1.2
tcp-retry 1000
end
5

ローカル ゲートウェイ信頼プールを更新します。

デフォルトの Trustpool バンドルには、 Webex CallingへのTLS接続の確立中にサーバー側の証明書を検証するために必要な「DigiCert Root CA」証明書や「IdenTrust Commercial」証明書が含まれていません。

最新版をダウンロードしてください「Cisco Trusted Core Root Bundle 」送信元http://www.cisco.com/security/pki/をクリックして、trustpool バンドルを更新します。

  1. DigiCert ルート CA および IdenTrust 商用証明書が存在するかどうかを確認します。

    show crypto pki trustpool | include DigiCert
  2. DigiCert ルート CA および IdenTrust 商用証明書が存在しない場合は、次のように更新します。

    configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b
    Reading file from http://www.cisco.com/security/pki/trs/ios_core.p7b
    Loading http://www.cisco.com/security/pki/trs/ios_core.p7b 
    % PEM files import succeeded.
    end
    

     

    また、証明書バンドルをダウンロードして、ローカル サーバまたはローカル ゲートウェイのフラッシュ メモリからインストールこともできます。

    例:

    crypto pki trustpool import clean url flash:ios_core.p7b
  3. 確認:

    show crypto pki trustpool | include DigiCert
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    

    show crypto pki trustpool | include IdenTrust Commercial
    cn=IdenTrust Commercial Root CA 1
    cn=IdenTrust Commercial Root CA 1

始める前に

Control Hub の手順を完了して、ロケーションを作成し、そのロケーションにトランクを追加してください。 次の例では、Control Hub から情報を取得します。
1

次のコマンドを入力して、ローカル ゲートウェイアプリケーションをオンにします。参照Cisco Webex Callingのポート参照情報は次のリストに追加する必要がある最新のIPサブネットです。

configure terminal 
voice service voip
ip address trusted list
ipv4 x.x.x.x y.y.y.y
exit
allow-connections sip to sip
media statistics
media bulk-stats
no supplementary-service sip refer
no supplementary-service sip handle-replaces
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
sip
g729 annexb-all
early-offer forced
asymmetric payload full
end

構成のフィールドの説明はここにあります。

電話料金詐欺の防止

voice service voip
ip address trusted list
ipv4 x.x.x.x y.y.y.y
  • ローカル ゲートウェイが次のような正当なVoIPコールを期待するエンティティのソースIPアドレスを有効にします。 Webex Callingピア、 Unified CMノード、およびIP PSTN です。

  • デフォルトで、LGW は、信頼リストにない IP アドレスからのすべての着信 VoIP コール セットアップをブロックします。 「セッション ターゲットIP 」またはサーバー グループを持つダイヤルピアからのIPアドレスは、デフォルトで信頼されているため、ここに入力する必要はありません。

  • リストのIPIPは、地域Webex Callingセットアップする必要があります。 詳細については、「Webex Calling のポート参照情報」を参照してください。


     

    LGW が制限されたコーン NAT を備えたファイアウォールの背後にある場合、 Webex Callingに面しているインターフェイスのIPアドレスの信頼済みリストを無効にすることをお勧めします。 ファイアウォールは、未承諾の着信VoIPからすでに保護しています。 無効化することで、長期的な設定のオーバーヘッドが削減されます。次の理由から、 Webex Callingピアは固定されたままになり、いずれの場合でもピアに対してファイアウォールを構成する必要があります。

  • 他のインターフェイスに他のIPアドレスを設定します。例: 必ずUnified CMアドレスを内向きのインターフェイスに追加します。

  • IPアドレスはホストのIPと一致する必要があり、 outbound-proxy の解決時に テナント 200。

    電話料金の詐欺行為を防ぐためにIPアドレス信頼リストを使用する方法についての詳細は、次を参照してください。 IPアドレス信頼を選択します。

voice service voip
 media statistics 
 media bulk-stats 

メディア

  • メディア統計情報

    ローカル ゲートウェイでメディア監視を有効にします。

  • メディアの一括統計

    一括コール統計のためにコントロール プレーンがデータ プレーンを投票できるようにします。

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

SIP-to-SIP 基本機能

allow-connections sip to sip
  • SIP から IP への接続を許可します。

  • デフォルトでは、Cisco IOS または IOS XE 音声デバイスは、着信 VoIP レッグが VoIP として外出することを許可しません。

    詳細については、次のサイトを参照してください。接続を許可を選択します。

補足サービス

no supplementary-service sip refer
no supplementary-service sip handle-replaces

REFER を無効にして、置き換えヘッダーのダイアログIDをピア ダイアログIDに置き換えます。 詳細については、次のサイトを参照してください。補足サービス SIPを選択します。

Fax プロトコル

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

FAX トラフィックは暗号化されませんが、FAX 転送に T.38 を有効にします。 このコマンドの詳細については、次を参照してくださいFax プロトコル t38(音声サービス)を選択します。

グローバルスタンを有効化

stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
  • コールをWebex Callingユーザ(たとえば、着信側と発信側の両方がWebex Callingメディアをアンカーする場合はWebex Calling SBC)、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

  • ローカル ゲートウェイのスタン バインディング機能により、ローカルで生成されたスタン要求を、ネゴシエートされたメディア パスを介して送信できます。 初期の状態がファイアウォールのピンホールを開くのに役立ちます。

  • スタンパスワードは、ローカル ゲートウェイがスタンメッセージを送信するための前提条件です。 Cisco IOS/IOS XE ベースのファイアウォールを設定して、パスワードを確認し、ピンホールをダイナミックに開くことができます (たとえば、明示的な in-out ルールなし)。 ただしローカル ゲートウェイ展開の場合は、ファイアウォールを静的に構成し、 Webex Calling SBC サブネット。 そのため、ファイアウォールは SBC サブネットをすべてのインバウンドUDPパケットとして扱う必要があります。このため、パケットの内容を明示的に確認せずにピンホールを開くことができます。

詳細については、次のサイトを参照してください。スタンフローデータエージェント-idおよびスタンフローデータ共有シークレットを選択します。

G729

sip
g729 annexb-all

G729 のすべてのバリアントを許可します。 詳細については、次のサイトを参照してください。 g729 annexb-all

SIP

early-offer forced

ローカル ゲートウェイに、隣接ピアからの確認応答待機の代わりに、初期 INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。

2

「SIP Profile 200」を設定します。

voice class sip-profiles 200
rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1"
rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1"
rule 20 request ANY sip-header From modify ">" ";otg=hussain2572_lgu>"
rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

構成のフィールドの説明はここにあります。

  • ルール 9

    ヘッダーを “SIP-Req-URI” としてリストされ、次のようにリストされなくなります: “SIP-Req-URL” です。

    このルールにより SIP URI と SIP URL の間で変換されます。以下の理由により、 Webex Callingは、要求または応答メッセージで SIP URI をサポートしませんが、次のような SRV クエリに対してそれらを必要とします。 _sips._tcp.<outbound-proxy>.
  • ルール 20

    From ヘッダーを変更して Control Hub からのトランク グループ OTG/DTG パラメーターを含め、エンタープライズ内のローカル ゲートウェイ サイトを固有に識別します。

  • すべてのトラフィックに対して、SIP プロファイルを音声クラス テナント 200(後で取り上げる)に適用します。 Webex Callingを選択します。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

    ルールコマンドの詳細については、次を参照してください。ルール(音声トランスレーション ルール)を選択します。

3

コーデックプロファイル、スタン定義、 SRTP暗号スイートを設定します。


voice class codec 99
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw 
exit
voice class srtp-crypto 200
 crypto 1 AES_CM_128_HMAC_SHA1_80
exit
voice class stun-usage 200
 stun usage firewall-traversal flowdata
 stun usage ice lite
exit

 

Opus コーデックのネゴシエーションとトランスコーディングは、SIP から SIP へのコールでのみ使用できます。 T1/E1/FXOトランクの場合、コーデックの基本設定1 opus音声クラスコーデック99の設定

構成のフィールドの説明はここにあります。

  • 音声クラス コーデック99

    セッションに対して g711(mu-law と a-law)コーデックを許可します。 すべてのダイヤルピアに stu を適用します。 詳細については、次のサイトを参照してください。音声クラス コーデックを選択します。

  • 音声クラス srtp-crypto200

    voice class srtp-crypto 200
    crypto 1 AES_CM_128_HMAC_SHA1_80

    SHA1 を指定します。_ 80 を、ローカル ゲートウェイがオファーと応答の SDP で提供する唯一のSRTP暗号スイートとして使用します。 Webex Calling は SHA180 のみをサポートします。_ 音声クラス コマンドの詳細については、以下を参照してください。音声クラス SRTP 暗号化を選択します。

  • に適用 音声クラス テナント200(後述) - Webex Calling。

  • 音声クラスの使い方200

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

    スタンの使用を定義します。 すべてのWebex Calling向きの (2XX タグ) ダイヤルピアに適用して、 Unified CM電話が別のWebex Calling電話に通話を転送する際に方向なし音声を回避します。 参照先ファイアウォールの使用を停止する-トラバーサル フローデータおよびスタン使用アイスライトを選択します。


 

ITSP SBC のアンカー メディアとローカル ゲートウェイが NAT の背後にある場合、ITSP からの受信メディア ストリームを待ちます。 ダイヤルピアに面した ITSP で sun コマンドを適用できます。


 

メディア パスの最適化を使用したコール フローには、ice-lite のスタン使用が必要です。 ICE-lite ベースのメディア最適化のために Cisco SIP-to-TDM ゲートウェイをサポートするには、回避策として TDM ゲートウェイのループバック ダイヤル ピアを設定します。 技術的な詳細については、アカウントまたは TAC チームにお問い合わせください。

4

Control Hub パラメータをローカル ゲートウェイ設定にマッピングします。

追加Webex Callingをローカル ゲートウェイ内のテナントとして共有します。 でローカル ゲートウェイを登録するには、構成が必要です。 音声クラス テナント 200だ 次の画像に示すように、Control Hub のトランク情報ページからその構成の要素を取得する必要があります。 次の例は、それぞれのローカル ゲートウェイ CLI にマッピングされるフィールドを示しています。

テナントの適用200すべてのWebex Callingに直面しているダイヤルピア(タグ) をローカルゲートウェイ構成内で行います。2xx 音声クラス テナント機能により、SIP トランク パラメータをグループ化して設定できます。通常は音声サービスVoIPと SIP ua の下で行われる作業です。 テナントを設定し、ダイヤルピアの下で適用する場合、次の優先順位がローカル ゲートウェイ構成に適用されます。

  • ダイヤルピア設定

  • テナント構成

  • グローバル構成(音声サービスVoIP /sip-ua)

5

設定音声クラス テナント200のコマンドを使用して、Control Hub から取得したパラメータに基づいて、ローカル ゲートウェイからWebex Callingへのトランク登録を有効にします。


 

次のコマンド ラインとパラメータは、例のみです。 独自の展開のパラメータを使用します。

voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls 
  url sips 
  error-passthru
  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 200 
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com  
  privacy-policy passthru

構成のフィールドの説明はここにあります。

音声クラス テナント 200

テナントの差別化されたサービスに許可する SIP トランク上の複数のテナントに対して特定のグローバル設定を有効にします。 詳細については、次のサイトを参照してください。音声クラス テナントを選択します。

登録事業者DNS:40462196.cisco-bcld.comスキームsip期限切れ240更新比率50 tcp tls

2 分 (240 秒の50%) ごとに更新するように登録が設定されたローカル ゲートウェイのレジストラ サーバー。 詳細については、次のサイトを参照してください。登録事業者を選択します。

クレデンシャル番号 Hussain6346_LGU ユーザー名 Hussain2572_LGU パスワード 0 meX71]~)Vmf realm BroadWorks

トランク登録チャレンジの資格情報。 詳細については、次のサイトを参照してください。クレデンシャル (SIP UA)を選択します。

認証ユーザ名 Hussain6346_LGU パスワード 0 meX71]~)Vmf realm BroadWorks
認証ユーザ名 Hussain6346_LGU パスワード 0 meX71]~)Vmf realm 40462196.cisco-bcld.com

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

no remote-party-id

ID Webex Callingは PAI をサポートしているため、CIOアサート ID paiを選択します。 詳細については、次のサイトを参照してください。リモートパーティ IDを選択します。

connection-reuse

登録およびコール処理に対して同じ持続的な接続を使用する。 詳細については、次のサイトを参照してください。接続の再使用を選択します。

srtp クリプト 200

を定義する 音声クラス srtp-crypto 200SHA1_80を指定します(ステップ3で指定)。 詳細については、次のサイトを参照してください。音声クラス srtp-crypto。

session transport tcp tls

トランスポートをTLSに設定します。 詳細については、次のサイトを参照してください。セッション-トランスポートを選択します。

url sips

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

error-passthru

SIP エラー応答パススルー機能を指定します。 詳細については、次のサイトを参照してください。エラーpassthruを選択します。

asserted-id pai

ローカル ゲートウェイで PAI 処理をオンにします。 詳細については、次のサイトを参照してください。アサート IDを選択します。

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

Webex Calling に面したソース インターフェイスをシグナリングするためのソース IP アドレスを設定します。

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

Webex Calling に面するメディア ソース インターフェイスのソース IP アドレスを設定します。 バインド コマンドの詳細については、次を参照してください:製本を選択します。

no pass-thru content custom-sdp

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

sipプロファイル 200

SIP を SIP に変更し、次で定義されているように、INVITE および REGISTER メッセージの回線/ポートを修正します: SIP プロファイル200を選択します。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

アウトバウンドプロキシ dns:la01.sipconnect-us10.cisco-bcld.com

Webex Calling SBC にアクセスします。 詳細については、次のサイトを参照してください。アウトバウンド-プロキシを選択します。

privacy-policy passthru

着信レッグから発信レッグにプライバシーヘッダー値を透過的に通過します。 詳細については、次のサイトを参照してください。プライバシーポリシーを選択します。

テナントを定義した後200ローカル ゲートウェイ内で SIP VoIPTLSピアを設定している場合、ゲートウェイはWebex Calling 、この時点で、アクセス SBC はローカル ゲートウェイに証明書を提示します。 ローカル ゲートウェイはWebex Calling以前に更新されたCAルートバンドルを使用してSBC証明書にアクセスします。 ローカル ゲートウェイ との間で永続的なTLSセッションを確立し、 Webex Calling SBC にアクセスします。 ローカル ゲートウェイはその後、チャレンジを受けるアクセス SBC に REGISTER を送信します。 登録 AOR は number@domain です。 番号は資格情報の「number」パラメーターから取得され、ドメインは「registrar dns:<fqdn>を使用します。 登録がチャレンジされた場合:

  • イベント、登録者、出席者にすばやくアクセスするため、ユーザー名、パスワード、および領域パラメータを資格情報を入力して、ヘッダーと SIP プロファイル 200 を構築します。

  • SIPS url を SIP に変換します。

Access SBC から 200 OKを受信したら、登録は成功です。

この展開ではローカル ゲートウェイで以下の設定が必要です。

  1. 音声クラス テナント—テナントと同様に ITSP に面しているダイヤルピア向けに他のテナントを作成します。 200をWebex Callingします。

  2. 音声クラス URI —ローカル ゲートウェイで終端するさまざまなトランクの主催者IPアドレス/ポートのパターンを定義します:

    • Webex Calling LGW に

    • LGW 上の PSTN SIP トランク終端

  3. 発信ダイヤルピア— LGW から ITSP SIP トランクとWebex Callingを選択します。

  4. 音声クラス DPG —着信ダイヤルピアから発信ダイヤルピアをターゲットにするために呼び出すことができます。

  5. 着信ダイヤルピア—ITSPからの着信コール レッグを受け付け、 Webex Callingを選択します。

次の画像に示すように、パートナーがホストするローカル ゲートウェイのセットアップ、または顧客サイトのゲートウェイの設定を使用します。

1

以下の音声クラス テナントを設定します:

  1. 音声クラス テナントを適用100をIP PSTN に面するすべての発信ダイヤルピアに送信します。

    voice class tenant 100 
    session transport udp
    url sip
    error-passthru
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
  2. 音声クラス テナントを適用300をIP PSTN からすべての着信ダイヤルピアに送信します。

    voice class tenant 300 
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
2

次の音声クラス uri を設定します。

  1. ITSP のホスト IP アドレスを定義:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Control Hub のトランク グループ OTG または DTG パラメーターに基づいて、エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するパターンを定義します。

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    ローカル ゲートウェイでは現在、下線」はサポートされていません。_を一致パターンに追加します。 回避策として、ドット「.」を使用できます (任意のものを)「_」にマッチさせます。

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
    Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
    pattern :8934
    
3

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

  1. IP PSTN に向かう発信ダイヤルピア:

    dial-peer voice 101 voip 
    description Outgoing dial-peer to IP PSTN
    destination-pattern BAD.BAD
    session protocol sipv2
    session target ipv4:192.168.80.13
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad

    構成のフィールドの説明はここにあります。

    dial-peer voice 101 voip
     description Outgoing dial-peer to PSTN
    

    次のタグでVoIPダイヤルピアを定義します101管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    destination-pattern BAD.BAD

    ダイヤルピアを選択できます。 101を選択します。 しかし、dpg ステートメントを使用してインバウンドから直接、発信ダイヤルピアを呼び出し、ディジット パターンマッチ基準をバイパスします。 宛先パターン CLI によって許可される英数字桁に基づいた任意のパターンを使用している。

    session protocol sipv2

    ダイヤルピアが101 SIP コール レッグを処理します。

    session target ipv4:192.168.80.13

    コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 この場合、ITSP の IP アドレスです。

    voice-class codec 99

    Codec 基本設定リスト 99 がこのダイヤルピアに使用されることを示します。

    dtmf-relay rtp-nte

    このコール レッグで期待される DTMF 機能として、RTP-NTE (RFC2833) を定義します。

    voice-class sip tenant 100

    ダイヤルピアはテナントからすべてのパラメータを継承します100その同じパラメータがダイヤルピアの下で定義されていない限り。

    no vad

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

  2. 発信ダイヤルピアWebex Calling (発信ダイヤル ピアを更新して、着信ダイヤル ピアとして機能するWebex Calling後の構成ガイドで参照してください)。

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target sip-server
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class stun-usage 200
    no voice-class sip localhost
    voice-class sip tenant 200
    srtp
    no vad
    

    コマンドの説明:

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

    次のタグでVoIPダイヤルピアを定義します200201管理とトラブルシューティングを簡単にするためのわかりやすい説明を付けます

    session target sip-server

    グローバル SIP サーバーがこのダイヤルピアからのコールの宛先であることを示します。 Webex Callingで定義するサーバテナント 200はダイヤルピアのために継承されます200201を選択します。

    voice-class stun-usage 200

    ローカル ゲートウェイ上でローカルに生成されたスタン要求を、ネゴシエートされたメディア パスを介して送信することを許可します。 スタンがファイアウォールのピンホールを開くのを支援します。

    no voice-class sip localhost

    発信メッセージの From、Call- ID、および Remote-Party- IDヘッダーで、物理IPアドレスの代わりにDNSローカル主催者名の置換を無効にします。

    voice-class sip tenant 200

    ダイヤルピアはテナントからすべてのパラメータを継承します200 (LGW =-- Webex Callingトランクなど)、ダイヤルピアの下で同じパラメータを定義する場合を除きます。

    srtp

    コール レッグのSRTPを有効にします。

    no vad

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

4

次のダイヤルピア グループ (dpg) を設定します:

  1. ダイヤルピア グループ 100 を定義します。 発信ダイヤルピア 101 は、ダイヤルピア グループ 100 を呼び出す着信ダイヤルピアのターゲットです。 適用するDPG 100の着信ダイヤルピア 200201 にWebex Calling --[LGW] --[PSTN]パス名を指定します。

    voice class dpg 100
    description Incoming WxC(DP200201) to IP PSTN(DP101)
    dial-peer 101 preference 1
    
  2. ダイヤルピア グループ 200 を発信ダイヤルピア 200201 で、PSTN --> LGW --> Webex Calling パスのターゲット200201として定義します。 DPG を適用200着信ダイヤルピア100を指定できます。

    voice class dpg 200
    description Incoming IP PSTN(DP100) to Webex Calling(DP200201)
    dial-peer 200201 preference 1
    
5

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

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN
    session protocol sipv2
    destination dpg 200
    incoming uri via 100
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 300
    no vad
    

    構成のフィールドの説明はここにあります。

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    ダイヤルピアが100 SIP コール レッグを処理します。

    incoming uri via 100

    音声クラス uri を指定します。 100 IP PSTN から VIA ヘッダーの主催者IPアドレスのローカル ゲートウェイへのすべての着信トラフィックを照合します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    destination dpg 200

    ダイヤル ピア グループを指定します200入力して発信ダイヤル ピアを選択します。 ダイヤルピア グループの設定についての詳細は、次を参照してください音声クラス dpgを選択します。

    voice-class sip tenant 300

    ダイヤルピアはテナントからすべてのパラメータを継承します300その同じパラメータがダイヤルピアの下で定義されていない限り。

    no vad

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

  2. Webex Calling コール レッグの着信ダイヤルピア:

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling
    max-conn 250
    destination dpg 100
    incoming uri request 200
     

    構成のフィールドの説明はここにあります。

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

    タグ が付いたVoIPダイヤルピアを更新します200201管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    incoming uri request 200

    音声クラス uri を指定します。 200に一致するすべての着信トラフィックをWebex Calling要求URIの一意の dtg パターンの LGW に送信し、エンタープライズ内のローカル ゲートウェイ サイトを一意に識別し、 Webex Callingエコシステム。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    destination dpg 100

    ダイヤル ピア グループを指定します100入力して発信ダイヤル ピアを選択します。 ダイヤルピア グループの設定についての詳細は、次を参照してください音声クラス dpgを選択します。

    max-conn 250

    LGW 間の同時通話数を 250 に制限します。 Webex Calling (単一のダイヤルピア向き) Webex Callingには、この記事で定義されているとおりの着信と発信の両方に適用されます。 ローカル ゲートウェイに関連する同時通話の制限の詳細については、ドキュメントを参照してくださいUnified CMからWebex Callingへの移行を選択します。

PSTN から Webex Calling

ローカル ゲートウェイのすべての着信IP PSTN コール レッグをダイヤルピアと一致させる100をクリックして、VIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 DPG 200発信ダイヤルピアを呼び出します200201 、にはWebex Callingサーバをターゲット接続先として設定します。

Webex Calling から PSTN

すべての着信に一致Webex Callingダイヤルピアを持つローカル ゲートウェイのコール レッグ200201を使用して REQUEST URIヘッダー パターンの一致基準を、このローカル ゲートウェイ展開に固有のトランク グループ OTG / DTG パラメータを定義します。 DPG 100発信ダイヤルピアを起動します101 、ターゲット宛先としてIP PSTN IPアドレスを持つ。

この展開ではローカル ゲートウェイで以下の設定が必要です。

  1. 音声クラス テナント—次のように、 Unified CMおよび ITSP に面するダイヤルピア用に追加のテナントを作成しますテナント 200作成することができますWebex Callingダイヤルピアに直面します。

  2. 音声クラス URI —以下から LGW で終端するさまざまなトランクの主催者IPアドレス/ポートのパターンを定義します。

    • PSTN の宛先としてのUnified CMから LGW へ

    • Unified CMから LGW へWebex Calling移動先

    • Webex Calling LGW 目的地に

    • LGW 上の PSTN SIP トランク終端

  3. 音声クラス サーバ グループ—外線トランクのIPアドレス/ポートを次のものから指定できます。

    • LGW からUnified CM

    • LGW からWebex Calling

    • LGW から PSTN SIP トランク

  4. 発信ダイヤルピア—発信コール レッグは以下からルーティングできます。

    • LGW からUnified CM

    • ITSP SIP トランク

    • Webex Calling

  5. 音声クラス DPG —着信ダイヤルピアから発信ダイヤルピアをターゲットするために呼び出すことができます。

  6. 着信ダイヤルピア: Unified CM、ITSP、 Webex Callingを選択します。

1

以下の音声クラス テナントを設定します:

  1. 音声クラス テナントを適用100 Unified CMとIP PSTN に面したすべての発信ダイヤルピア上で、次のようにします。

    voice class tenant 100 
    session transport udp
    url sip
    error-passthru
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
  2. 音声クラス テナントを適用300 Unified CMとIP PSTN からのすべての着信ダイヤルピア上:

    voice class tenant 300 
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
2

次の音声クラス uri を設定します。

  1. ITSP のホスト IP アドレスを定義します。

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Control Hub のトランク グループ OTG / DTG パラメーターに基づいて、エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するパターンを定義します。

    voice class uri 200 sip
    pattern dtg=hussain2572.lgu
    

     

    ローカル ゲートウェイは現在、下線「_を一致パターンに追加します。 回避策として、ドット「.」を使用してください (任意のものを)「_」にマッチさせます。

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
    Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
    pattern :8934
    
  3. Webex Calling トランクの Unified CM シグナリング VIA ポートを定義します。

    voice class uri 300 sip
    pattern :5065
    
  4. PSTN トランクのUnified CMソースシグナリングIPおよび VIA ポートを定義します。

    voice class uri 302 sip
    pattern 192.168.80.60:5060
    
3

以下の音声クラス サーバー グループを設定:

  1. Unified CMトランクのターゲット主催者IPアドレスとUnified CMグループ 1 (5 ノード) のポート番号を定義します。 Unified CM は Webex Calling トランク (Webex Calling <->LGW --> Unified CM) の着信トラフィックに対してポート 5065 を使用します。

    voice class server-group 301
    ipv4 192.168.80.60 port 5065
    
  2. 適宜、 Unified CMトランクのターゲット主催者IPアドレスとUnified CMグループ 2 のポート番号を定義します。

    voice class server-group 303
    ipv4 192.168.80.60 port 5065
    
  3. Unified CMグループ 1 (5 ノード) に対する Unified Unified CMトランクのターゲット主催者IPアドレスを定義します。 Unified CM は PSTN トランクで着信トラフィックに対してデフォルトのポート 5060 を使用します。 ポート番号が指定されていない場合は、デフォルトの 5060 ポートを使用できます。 (PSTN =-- LGW - % Unified CM)

    voice class server-group 305
    ipv4 192.168.80.60
    
  4. 適宜、 Unified CM Unified CMトランクのターゲット主催者IPアドレスを定義します。

    voice class server-group 307 
    ipv4 192.168.80.60
    
4

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

  1. IP PSTN に向かう発信ダイヤルピア:

    dial-peer voice 101 voip 
    description Outgoing dial-peer to IP PSTN
    destination-pattern BAD.BAD
    session protocol sipv2
    session target ipv4:192.168.80.13
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    

    構成のフィールドの説明はここにあります。

    dial-peer voice 101 voip
    description Outgoing dial-peer to PSTN

    次のタグでVoIPダイヤルピアを定義します101および管理とトラブルシューティングを容易にするために、意味のある説明が与えられます。

    destination-pattern BAD.BAD

    ダイヤルピアを選択できます。 101を選択します。 しかし、dpg ステートメントを使用してインバウンドから直接、発信ダイヤルピアを呼び出し、ディジット パターンマッチ基準をバイパスします。 宛先パターン CLI によって許可される英数字桁に基づく任意のパターンを使用している。

    セッションプロトコル sipv2

    ダイヤルピアが101 SIP コール レッグを処理します。

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

    コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 (この場合は、ITSP のIPアドレスです)。

    音声クラス コーデック 99

    コーデックの基本設定リストを示す 99.は、このダイヤルピアに使用されます。

    音声クラス SIP テナント 100

    ダイヤルピアはテナントからすべてのパラメータを継承します100ダイヤルピアの下で同じパラメータを定義しない限り。

  2. 発信ダイヤルピアWebex Calling (発信ダイヤルピアを更新して, 着信ダイヤルピアとしてサービスを提供しますWebex Calling ):

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target sip-server
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class stun-usage 200
    no voice-class sip localhost
    voice-class sip tenant 200
    srtp
    no vad
    

    構成のフィールドの説明はここにあります。

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

    次のタグでVoIPダイヤルピアを定義します200201管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    session target sip-server

    グローバル SIP サーバーがダイヤルピアからのコールの宛先であることを示します。 200201を選択します。 Webex Calling定義されているサーバテナント 200はダイヤルピアのために継承されます200201を選択します。

    音声クラスの stun 使用 200

    ローカルで生成されたスタン要求が、ネゴシエートされたメディア パスを介して送信することを許可します。 スタンがファイアウォールのピンホールを開くのを支援します。

    no voice-class sip localhost

    発信メッセージの From、Call- ID、および Remote-Party- IDヘッダーで、物理IPアドレスの代わりにDNSローカル主催者名の置換を無効にします。

    音声クラス SIP テナント 200

    ダイヤルピアはテナントからすべてのパラメータを継承します200 (LGW =-- Webex Callingトランク) ダイヤルピアの下で同じパラメータを定義しない限り。

    srtp

    コール レッグのSRTPを有効にします。

  3. Unified CM に向かう発信ダイヤルピアWebex Callingトランク:

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling - Nodes 1 to 5
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 301
    voice-class codec 99
    voice-class sip bind control source-interface GigabitEthernet 0/0/2
    voice-class sip bind media source-interface GigabitEthernet 0/0/2
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    

    構成のフィールドの説明はここにあります。

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling – Nodes 1 to 5

    次のタグでVoIPダイヤルピアを定義します301管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    セッション サーバー グループ 301

    ダイヤルピアのセッション ターゲットIPの代わりに、宛先サーバ グループをポイントしています (ダイヤルピア 301 の場合の server-group 301 ) を使用して複数のターゲット UCM ノードを定義しますが、この例では単一のノードのみを表示しています。

    発信ダイヤルピアのサーバ グループ

    DPG の複数のダイヤルピアとダイヤルピアサーバーグループ内の複数のサーバーを使用して、すべてのUnified CMコール処理サブスクライバーにコールをランダムに配信したり、定義済みの設定に基づいてハントしたりできます。 各サーバー グループは、最大 5 台のサーバーを持つことができます (ポートあり、またはポートなしの IPv4/v6)。 5 つ以上のコール処理サブスクライバが使用している場合のみ、2 番目のダイヤルピアと 2 番目のサーバーグループが必要です。

    詳細については、次のサイトを参照してください。発信ダイヤルピアのサーバ グループ場所: Cisco Unified Border Element構成ガイド - Cisco IOS XE 17.6 以降を選択します。

  4. Unified CM に向かう 2 番目の送信ダイヤルピアWebex Calling trunk: 5 つ以上のUnified CMノードがある場合。

    dial-peer voice 303 voip
    description Outgoing dial-peer to CUCM-Group-2 
    for inbound from Webex Calling - Nodes 6 to 10
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 303
    voice-class codec 99
    voice-class sip bind control source-interface GigabitEthernet 0/0/2
    voice-class sip bind media source-interface GigabitEthernet 0/0/2
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
  5. Unified CM の PSTN トランクに向かう送信ダイヤルピア:

    dial-peer voice 305 voip
    description Outgoing dial-peer to CUCM-Group-1for inbound from PSTN - Nodes 1 to 5
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 305
    voice-class codec 99 
    voice-class sip bind control source-interface GigabitEthernet 0/0/2
    voice-class sip bind media source-interface GigabitEthernet 0/0/2
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    
  6. 5 つ以上のUnified CMノードをもつ場合に、Unified CM の PSTN トランクに向かう 2 番目の送信ダイヤルピア。

    dial-peer voice 307 voip
    description Outgoing dial-peer to CUCM-Group-2 for inbound from PSTN - Nodes 6 to 10
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 307
    voice-class codec 99  
    voice-class sip bind control source-interface GigabitEthernet 0/0/2
    voice-class sip bind media source-interface GigabitEthernet 0/0/2
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    
5

以下の DPG を構成します。

  1. DPG 100 を定義します。 発信ダイヤルピア 101 は、ダイヤルピア グループ 100 を呼び出す着信ダイヤルピアのターゲットです。 適用するDPG 100着信ダイヤルピア 302 にUnified CM --/LGW --/PSTNパス:

    voice class dpg 100
    dial-peer 101 preference 1
    
  2. 発信ダイアル ピア 200201 に対する DPG 200 を Unified CM --> LGW --> Webex Calling パスに対して定義します。

    voice class dpg 200
    dial-peer 200201 preference 1
    
  3. DPG の定義300発信ダイヤルピアの301 または 303対応のWebex Calling --/LGW --/ Unified CMパス:

    voice class dpg 300
    dial-peer 301 preference 1
    dial-peer 303 preference 1
    
  4. 発信ダイアル ピア DPG 305 または 307 に対する 302 を PSTN --> LGW --> Unified CM パスに対して定義します。

    voice class dpg 302
    dial-peer 305 preference 1
    dial-peer 307 preference 1
    
6

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

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN
    session protocol sipv2
    destination dpg 302
    incoming uri via 100
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 300
    no vad
    

    構成のフィールドの説明はここにあります。

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    ダイヤルピアが100 SIP コール レッグを処理します。

    100 経由で 着信 uri

    音声クラス uri を指定します。 100を VIA ヘッダーの主催者IPアドレスでUnified CMから LGW へのすべての着信トラフィックに送信します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    宛先 DPG 302

    ダイヤルピア グループ を指定する 302 アウトバウンドダイヤルピアを選択します。 ダイヤルピア グループの設定についての詳細は、次を参照してください音声クラス dpgを選択します。

    音声クラス SIP テナント 300

    ダイヤルピアはテナントからすべてのパラメータを継承します300ダイヤルピアの下で同じパラメータを定義しない限り。

  2. Webex Calling コール レッグの着信ダイヤルピア:

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling
    max-conn 250
    destination dpg 300
    incoming uri request 200
     

    構成のフィールドの説明はここにあります。

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

    タグ が付いたVoIPダイヤルピアを更新します200201管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    着信 uri リクエスト 200

    音声クラス uri を指定します。 200をUnified CMから LGW へのすべての着信トラフィックに対して、リクエストURIの一意の dtg パターンで、エンタープライズ内およびWebex Callingエコシステム内のローカル ゲートウェイ サイトを一意に識別します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    宛先 DPG 300

    ダイヤルピア グループ を指定する 300 アウトバウンドダイヤルピアを選択します。 ダイヤルピア グループの設定についての詳細は、次を参照してください音声クラス dpgを選択します。

    マックスコン 250

    同時通話数を250 LGW とWebex Callingの間で、このガイドで定義されているとおり着信と発信の両方に対してWebex Callingに面した単一のダイヤルピアを想定しています。 ローカル ゲートウェイに関連する同時通話の制限の詳細については、ドキュメントを参照してください。 Unified CMからWebex Callingへの移行を選択します。

  3. 宛先として Webex Calling をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling
    session protocol sipv2
    destination dpg 200
    incoming uri via 300
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 300
    no vad
    

    構成のフィールドの説明はここにあります。

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    300 経由で 着信 uri

    音声クラスURIを指定します300を via ソースポート (5065) のUnified CMから LGW へのすべての着信トラフィックに送信します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    宛先 DPG 200

    ダイヤルピア グループ を指定する 200 アウトバウンドダイヤルピアを選択します。 ダイヤルピア グループの設定についての詳細は、次を参照してください音声クラス dpgを選択します。

    音声クラス SIP テナント 300

    ダイヤルピアはテナントからすべてのパラメータを継承します300ダイヤルピアの下で同じパラメータを定義しない限り。

  4. 宛先PSTNとして PSTN をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN
    session protocol sipv2
    destination dpg 100
    incoming uri via 302
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 300
    no vad
    

    構成のフィールドの説明はここにあります。

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN

    次のタグでVoIPダイヤルピアを定義します302管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    incoming uri via 302

    音声クラス uri を指定します。 302を via ソースポート (5065) のUnified CMから LGW へのすべての着信トラフィックに送信します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    宛先 DPG 100

    ダイヤルピア グループ を指定する 100 アウトバウンドダイヤルピアを選択します。 ダイヤルピア グループの設定についての詳細は、次を参照してください音声クラス dpgを選択します。

    音声クラス SIP テナント 300

    ダイヤルピアはテナントからすべてのパラメータを継承します300ダイヤルピアの下で同じパラメータを定義しない限り。

IP PSTN からUnified CM PSTN トランク

Webex CallingプラットフォームからUnified CM Webex Callingトランクへ

IP PSTN へのUnified CM PSTN トランク

Webex CallingプラットフォームへのUnified CM Webex Callingトランク

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

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

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

  • 統合ログファイルを生成する

  • ユーザーが指定したネットワーク ロケーションへのファイルのアップロード (HTTPS、SCP、 FTPサーバーなど)

TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名します。 各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。

開始する前に:

  • ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。

  • ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。

  • メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。

前提条件

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

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

  2. デバイスでCisco IOS XE 17.3.2 以降を実行している場合は、プロアクティブ通知の送信に使用するセキュアなメールサーバーを構成します。

    configure terminal 
    call-home  
    mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    end 
  3. 環境変数を構成しますds_emailを通知する管理者のメールアドレスを入力します。

    configure terminal 
    call-home  
    diagnostic-signature 
    environment ds_email <email address> 
    end 

16.11.1 以降を実行しているローカル ゲートウェイ

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

  2. デバイスで 17.3.2 以前のバージョンを実行している場合は、プロアクティブ通知の送信に使用するメールサーバーを構成します。

    configure terminal 
    call-home  
    mail-server <email server> priority 1 
    end 
  3. 通知を受け取る管理者のメールアドレスで環境変数 ds_email を構成します。

    configure terminal 
    call-home  
    diagnostic-signature 
    environment ds_email <email address>
    end 

16.9.x バージョンを実行しているローカルゲートウェイ

  1. 次のコマンドを入力して、診断署名を有効にします。

    configure terminal 
    call-home reporting contact-email-addr sch-smart-licensing@cisco.com  
    end  
  2. デバイスで 17.3.2 以前のバージョンを実行している場合は、プロアクティブ通知の送信に使用するメールサーバーを構成します。

    configure terminal 
    call-home  
    mail-server  <email server> priority 1 
    end 
  3. 通知を受け取る管理者のメールアドレスで環境変数 ds_email を構成します。

    configure terminal 
    call-home  
    diagnostic-signature 
    environment ds_email <email address> 
    end 

以下に、 Cisco IOS XE 17.3.2 で実行されているローカルゲートウェイのプロアクティブ通知を送信するための構成例を示しますtacfaststart@gmail.comセキュアなSMTPサーバーとして Gmail を使用する方法を説明します。

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 をサポートする一般的な Web ベースの Gmail クライアントではないため、専用の Gmail アカウント設定を構成し、デバイスからのメールを適切に処理するための専用権限を指定する必要があります。

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

  2. 「Google 以外のアプリを使って第三者があなたのアカウントにサインインすることができなくなりました」というメールが Gmail から送られてきたら、「はい、それは私です」と回答します。

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

高いCPU使用率の監視

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

  1. を使用する SNMPを表示 コマンドで SNMP を有効にします。 有効にしない場合は、snmpサーバーマネージャ コマンド

    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@<server name or ip>/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. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「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 は、 Webex Callingクラウドをもつローカルゲートウェイ SIP トランクの登録解除を 60 秒ごとにチェックします。 登録解除イベントが検出されると、メールと syslog 通知が生成され、登録解除が 2 回発生した後に DS 自体がアンインストールされます。 下記の手順を実行して、署名をインストールしてください。

  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@<server name or ip>/DS_64117.xml bootflash: 
  3. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64117.xml 
    Load file DS_64117.xml success 
    LocalGateway#  
  4. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。

異常な通話切断の監視

この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。  エラーカウントが前回の投票から 5 以上増えている場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. を使用する SNMPを表示 コマンドを使用して、SNMP が有効になっているかどうかを確認します。 有効になっていない場合は、snmpサーバーマネージャ コマンド

    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@<server name or ip>/DS_65221.xml bootflash:
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
    
  5. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示コマンドを実行し、 を使用して署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。

問題をトラブルシューティングするための診断署名をインストールする

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

また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 追加の DS 環境変数を構成しますds_fsurl_prefix収集された診断データがアップロードされるCisco TACファイルサーバーパス (cxd.cisco.com) です。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャーを次のコマンドで実行できます。 必要に応じて、サポートケースマネージャの [添付] セクションでファイルアップロードトークンを生成できます。

    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
    end 

    例:

    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド

    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@<server name or ip>/DS_64224.xml bootflash: 
    copy ftp://username:password@<server name or ip>/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. 署名が正常にインストールされたことを確認してください。 call-home 診断署名の表示します。 ステータス列の値が「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 日

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    登録済み

    2020 年 11 月 08 日

診断署名の実行を確認する

次のコマンドでは、[状態] 列のcall-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間、コマンドは「実行中」に変わります。 出力は次のとおりですCall-home 診断署名統計の表示は、診断署名が対象イベントを検出してアクションを実行するかどうかを検証するための最適な方法です。 [Triggered/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

Call-home 診断署名統計の表示

DS ID

DS 名

トリガー済み/最大/アンインストール

平均実行時間(秒)

最長実行時間(秒)

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 コマンド出力などの重要な情報が含まれています。

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

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

call-home diagnostic-signature deinstall <DS ID> 

例:

call-home diagnostic-signature deinstall 64224 

 

展開でよく見られる問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Cisco IOS XE ゲートウェイの管理を改善するため、コントロールハブを通じてゲートウェイを登録し、管理することを推奨します。 これはオプションの設定です。 登録すると、コントロール ハブの設定検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定することができます。 現在、この機能をサポートしているのは登録ベースのトランクだけです。

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

このドキュメントでは、相互 TLS (mTLS) SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element (CUBE) を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 次の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調表示されます。

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

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

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

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

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

オンプレミスの Cisco Unified Communications Manager ソリューションと Webex Calling と相互運用しながら、次の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ設定を使用できます。 この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールの集中ルーティングと処理を提供します。 ハイレベル構成のアプローチは、図に示されています。

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。 オプションは、パブリックまたはプライベート(NATの背後)アドレッシングに提供されます。 SRV DNS レコードは、複数の CUBE インスタンス間でロードバランシングされない限り、オプションです。

始める前に

  • ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下が正しく動作するように設定および検証されていることを確認してください。

    • NTP

    • ACL

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

    • DNS

    • IPルーティング

    • IP アドレス

  • すべてのローカル ゲートウェイ展開で、サポートされている最小リリースの IOS XE 17.9 が必要です。

    • ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。

    • Catalyst Edge 8000シリーズのルーターには、DNA Essentialsのライセンスが必要です。

    • 大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。

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

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

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

  • 署名付き証明書をローカル ゲートウェイにインストールします (詳細な設定手順を以下に示します)。

    • パブリック認証局 (CA) は、Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局の詳細に従って、デバイス証明書に署名する必要があります。

    • Control Hub で設定された FQDN は、ルータの証明書の共通名(CN)またはサブジェクト代替名(SAN)である必要があります。 例:

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

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

      • トランクに FQDN または SRV を使用するかどうかにかかわらず、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスには、Control Hub で名前が設定されている必要があります。

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

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

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

希望する認証局 (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 cube1.lgwtrunking.com
     subject-name cn=cube1.lgw.com
     subject-alt-name cube1.lgw.com
     revocation-check none
     rsakeypair lgw-key
  3. 次の exec または configuration コマンドを使用して証明書署名リクエスト(CSR)を生成し、これを使用して、サポートされている CA プロバイダーから署名済み証明書を要求します。

    crypto pki enroll LGW_CERT
3

中間(またはルート)CA 証明書を使用して新しい証明書を認証し、証明書をインポートします。 次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here >
4

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


crypto pki import LGW_CERT certificate
<paste CUBE  X.509 base 64 certificate here>
5

TLS1.2 独占を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。


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

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

crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b
1

Control Hub で CUBE ホスト名 / SRV を使用して証明書ベースのトランクを作成し、その場所に割り当てます。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。

2

次のセクションの設定コマンドを使用して、Webex Calling および PSTN トランクで CUBE を構成します。


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
 no supplementary-service sip handle-replaces
 sip 
  early-offer forced
  asymmetric payload full
  sip-profiles inbound

構成のフィールドの説明はここにあります。

IP アドレス信頼済みリスト

IPV4 x.x.x.x y.y.y.y

  • CUBE が正当な VoIP コールを期待するエンティティのソース IP アドレスを定義します。

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

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データセンターの IP サブネットをリストに追加します。 参照先Webex Callingのポート参照情報をご覧ください。

  • 電話料金の詐欺行為を防ぐためにIPアドレス信頼リストを使用する方法についての詳細は、次を参照してください。 IPアドレス信頼を選択します。

モード ボーダー要素

allow-connections sip to sip

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


 

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

early-offer forced

CUBE は、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。

非対称ペイロード フル

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

3

を設定する 音声クラス コーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


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

構成のフィールドの説明はここにあります。

音声クラス コーデック100

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


 

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage ice lite

構成のフィールドの説明はここにあります。

音声クラススタン使用率100

すべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。


 

メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細については、アカウントまたは TAC チームにお問い合わせください。

5

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


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100
SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_
詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。
6

SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで構成されている場合、NAT を使用している場合は、次のようにプロファイルを設定するか、次のセクションにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に選択された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。


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

構成のフィールドの説明はここにあります。

ルール 10、ルール 20

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


 

ローカル ゲートウェイにパブリック IP アドレスを設定している場合は、次の手順をスキップします。

7

ゲートウェイが静的 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 11 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 30 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 80 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20
 rule 91 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 93 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
Webex Callingからの受信メッセージの SIP プロファイル

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

詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

8

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


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

構成のフィールドの説明はここにあります。

音声クラス sip-options-keepalive 100

キープアライブプロファイルを設定し、音声クラス構成モードを開始します。 エンドポイントへのハートビート接続が UP または DOWN 状態の場合、SIP アウトオブダイアログオプション 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 アドレスです。

9

Webex Calling からの着信メッセージを分類するための URI マッチングプロファイルを設定します。


voice class uri 110 sip
 pattern cube1.lgw.com

構成のフィールドの説明はここにあります。

音声クラス uri 100 sip

Webex Calling からの着信コールの FQDN の一致パターンを定義します。 音声クラス uri sip 基本設定を参照してください。

10

Webex Calling トランクの設定:

  1. テナントを使用して、特定のトランクに関連付けられたダイヤルピアに共通の動作を設定することをお勧めします。

    
    voice class tenant 100
      no remote-party-id
      srtp-crypto 100
      localhost dns:cube1.lgw.com
      session transport tcp tls
      no session refresh
      error-passthru
      bind control source-interface GigabitEthernet0/0/1
      bind media source-interface GigabitEthernet0/0/1
      no pass-thru content custom-sdp
      privacy-policy passthru
    !

    構成のフィールドの説明はここにあります。

    音声クラス テナント 100

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

    no remote-party-id

    Remote-Party-ID 翻訳を無効にします。

    srtp クリプト 100

    SRTPコール レッグ(接続)に優先される暗号スイートを設定します。 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

    localhost DNS: キューブ1.lgw.com

    発信メッセージの [送信元(From)]、[コール ID(Call-ID)]、および [リモートパーティー(Remote-Party-ID)] ヘッダーの物理的な IP アドレスを提供された FQDN に置き換えるように CUBE を設定します。

    session transport tcp tls

    トランスポートをTLSに設定します。 詳細については、次のサイトを参照してください。セッション-トランスポートを選択します。

    セッション更新なし

    SIP セッションの更新をグローバルに無効にします。

    バインドコントロールソース-インターフェイスGigabitEthernet0/0/1

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

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

    Webex Calling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細については、次のサイトを参照してください。製本を選択します。

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

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。

  2. Webex Callingへの発信ダイヤルピアを構成します。

    
    dial-peer voice 100 voip
     description OutBound Webex Calling
     destination-pattern bad.bad
     session protocol sipv2
     session target dns:<your edge proxy address>
     session transport tcp tls
     voice-class codec 100
     voice-class stun-usage 100
     voice-class sip rel1xx disable
     voice-class sip asserted-id pai
     voice-class sip profiles 100
     voice-class sip tenant 100
     voice-class sip options-keepalive profile 100
     dtmf-relay rtp-nte
     srtp
     no vad
    

    構成のフィールドの説明はここにあります。

    ダイヤルピアの音声 100 voip

    説明 アウトバウンド Webex Calling

    のタグを持つVoIPダイヤルピアを定義する 100で、管理とトラブルシューティングを容易にする意味のある説明を提供します。 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

    宛先パターン bad.bad

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。

    session protocol sipv2

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

    セッション ターゲット DNS: <your edge="" proxy="" address="">

    Control Hub から通話が送信される場所への Webex Calling エッジ プロキシ SRV アドレスを定義します。 たとえば、セッション ターゲット dns:us01.sipconnect.bcld.webex.com です。 詳細については、次のサイトを参照してください。セッション ターゲット (VoIPダイヤル ピア)を選択します。

    session transport tcp tls

    SIP ダイヤル ピアは、 TCPトランスポート層プロトコルではなくトランスポート レイヤ セキュリティ (TLS ) を使用します。

    音声クラス コーデック100

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

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

    ヘッダー変更プロファイル(パブリック IP または NAT アドレス)を発信メッセージに使用するように適用します。 詳細については、次のサイトを参照してください。音声クラスの sip プロファイルを選択します。

    音声クラス sip テナント100

    このダイヤルピアをテナント に追加する 100から、すべての一般的なトランク構成を受信します。

    音声クラス sip オプション-keepaliveプロファイル100

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

11

Webex Calling へのダイヤルピアに基づいてダイヤルピア グループを作成します。

  1. DPGを定義する 100 アウトバウンドダイヤルピア100からWebex Callingへ。 DPGについて 100 は、PSTN からの着信ダイヤルピアに適用されます。


voice class dpg 100
 description Incoming Webex Calling to IP PSTN
 dial-peer 100 

構成のフィールドの説明はここにあります。

ダイヤルピア 100

発信ダイヤルピアとダイヤルピアグループ を関連付ける 100だ 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

12

着信ダイヤルピアを設定して、Webex Calling からメッセージを受信します。 着信一致はURIリクエストに基づきます。


dial-peer voice 110 voip 
 description Inbound dial-peer from Webex Calling
 session protocol sipv2
 session transport tcp tls
 destination dpg 200
 incoming uri request 110
 voice-class codec 100
 voice-class stun-usage 100 
 voice-class sip profiles 110 
 voice-class sip srtp-crypto 100
 voice-class sip tenant 100 
 srtp

構成のフィールドの説明はここにあります。

音声クラス uri 100 sip

ダイヤルピアを Session Initiation Protocol(SIP)ユニフォームリソース識別子(URI)に一致させるための音声クラスを作成または変更する。 詳細については、音声クラス uri を参照してください。

session transport tcp tls

トランスポートをTLSに設定します。 詳細については、次のサイトを参照してください。セッショントランスポートを選択します。

宛先 DPG 200

ダイヤルピア グループ を指定する 200 は、PSTN または Unified Communications Manager に向かって発信ダイヤル ピアを選択します。 ダイヤルピア グループについての詳細は、次を参照してください。音声クラス dpgを選択します。

着信 uri リクエスト 110

VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子(URI)を一致させるために使用される音声クラスを指定します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

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

CUBE が静的 NAT の後ろにある場合にのみ必要で、SIP プロファイル 110 はパブリック IP アドレスをプライベート インターフェイス アドレスに変更します。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

音声クラス srtp-crypto 100

SRTPコール レッグ(接続)に優先される暗号スイートを設定します。 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

音声クラス SIP テナント 100

このダイヤル ピアをトランク テナントに関連付け、関連するすべての設定を継承できるようにします。 詳細については、「音声クラス SIP テナント」を参照してください。

srtp

このダイヤル ピアを使用するすべてのコールが暗号化されたメディアを使用するように指定します。 詳細については、「srtp」を参照してください。

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


 

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。

1

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


voice class uri 210 sip
  host ipv4:192.168.80.13
2

PSTN IP トランクに向かって次の発信ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

構成のフィールドの説明はここにあります。

ダイヤルピア ボイス 200 voip

説明 PSTN への発信ダイヤルピア

次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。 詳細については、次のサイトを参照してください。ダイヤルピア音声。

destination-pattern BAD.BAD

着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。

session protocol sipv2

ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。

session target ipv4:192.168.80.13

コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、次のサイトを参照してください。セッション ターゲット (VoIPダイヤル ピア)を選択します。

音声クラス コーデック 100

共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。 詳細については、次のサイトを参照してください。音声クラス コーデックを選択します。

dtmf-relay rtp-nte

コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、次のサイトを参照してください。 DTMFリレー ( IP)を選択します。

no vad

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

3

以下のダイヤルピア グループ (DPG) を構成します:

  1. PSTNに向けて発信ダイヤルピア200を使用してDPG 200を定義します。 Webex Calling からの着信ダイヤルピアに DPG 200 を適用します。

    
    voice class dpg 200
     description Incoming IP PSTN to Webex Calling
     dial-peer 200 
4

次のインバウンドダイヤルピアを設定します。

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

    
    dial-peer voice 210 voip
     description Incoming dial-peer from PSTN 
     session protocol sipv2
     destination dpg 100 
     incoming uri via 210 
     voice-class codec 100 
     dtmf-relay rtp-nte
     no vad
    

    構成のフィールドの説明はここにあります。

    ダイヤルピア ボイス 210 voip

    description PSTN からの着信ダイヤルピア

    210のタグを含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

    session protocol sipv2

    ダイヤルピア 210 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。

    210 経由の着信 uri

    VIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 210 で一致します。 詳細については、次のサイトを参照してください。着信 URLを選択します。

    destination dpg 100

    ローカル ゲートウェイの従来の発信ダイヤル ピア マッチング基準と、Webex Calling への接続先 DPG 100 をバイパスします。 ダイヤル ピア グループの設定についての詳細は、次を参照してください。音声クラス dpgを選択します。

    no vad

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

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

1

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

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
    voice class uri 310 sip
     pattern :5065
    
  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
    voice class uri 410 sip
     pattern :5060
    
2

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


 

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 リソース レコードを作成します。 各ホストとトランクのレコードを作成します。

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 アドレス。

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

3

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

  1. Webex Calling から Unified CM に向かって発信ダイヤルピア:

    
    dial-peer voice 300 voip
     description Outgoing dial-peer to CUCM from Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     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
    

    構成のフィールドの説明はここにあります。

    ダイヤルピア ボイス 300 voip

    説明 Webex Calling から CUCM への発信ダイヤルピア

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

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

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。

  2. PSTN から Unified CM に向かって発信ダイヤルピア:

    
    dial-peer voice 400 voip
     description Outgoing dial-peer to CUCM from PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     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
    

    構成のフィールドの説明はここにあります。

    ダイヤルピア ボイス 400 voip

    description PSTN から CUCM への発信ダイヤルピア

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。

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

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。

4

Unified CM へのコールに対して、次のダイヤル ピア グループ(DPG)を設定します。

  1. Webex Calling から Unified CM へのコールに対して、発信ダイヤルピア 300 に対して DPG 300 を定義します。

    
    voice class dpg 300
     dial-peer 300
     
  2. PSTN から Unified CM へのコールに対して、発信ダイヤルピア400 に対して DPG 400 を定義します。

    
    voice class dpg 400
     dial-peer 400
    
5

次の着信ダイヤルピアを変更して、PSTN および Webex Calling コールを Unified CM にルーティングします。

  1. Webex Calling からの通話の着信ダイヤルピアを変更する:

    
    dial-peer voice 110 voip
     no destination dpg 200
     destination dpg 300
    
  2. PSTN からのコールの着信ダイヤルピアを変更します。

    
    dial-peer voice 210 voip
     no destination dpg 100 
     destination dpg 400
    
  3. UCM から Webex Calling への通話の着信ダイヤル ピアを追加します。

    
    dial-peer voice 310 voip
     description Incoming dial-peer from CUCM for Webex Calling
     session protocol sipv2
     destination dpg 100
     incoming uri via 310 
     voice-class codec 100
     dtmf-relay rtp-nte
     no vad
    

    構成のフィールドの説明はここにあります。

    ダイヤルピア ボイス 310 voip

    説明 Webex Calling の CUCM からの着信ダイヤルピア

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

    310 からの着信 uri

    音声クラスURIを指定します300を via ソースポート (5065) のUnified CMから LGW へのすべての着信トラフィックに送信します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    destination dpg 100

    Webex Calling に向かって発信ダイヤル ピアを選択するには、ダイヤル ピア グループ 100 を指定します。 ダイヤル ピア グループの設定についての詳細は、次を参照してください。音声クラス dpgを選択します。

  4. 宛先PSTNとして PSTN をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

    
    dial-peer voice 410 voip
     description Incoming dial-peer from CUCM for PSTN
     session protocol sipv2
     destination dpg 200
     incoming uri via 410
     voice-class codec 100
     dtmf-relay rtp-nte
     no vad
    

    構成のフィールドの説明はここにあります。

    ダイヤルピア ボイス 311 voip

    description PSTN 用 CUCM からの着信ダイヤルピア

    410のタグを含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

    311 からの着信 uri

    VIA ポートの PSTN 接続先のローカル ゲートウェイへの Unified CM からのすべての着信トラフィックに一致する音声クラス URI 410 を指定します。 詳細については、次のサイトを参照してください。着信 URIを選択します。

    destination dpg 200

    PSTN に向かって発信ダイヤル ピアを選択するには、ダイヤル ピア グループ 200 を指定します。 ダイヤル ピア グループの設定についての詳細は、次を参照してください。音声クラス dpgを選択します。

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

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

  • show コマンド出力の収集

  • 統合ログファイルを生成する

  • ユーザーが指定したネットワーク ロケーションへのファイルのアップロード (HTTPS、SCP、 FTPサーバーなど)

TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名を行います。 各 DS ファイルには、システムによって割り当てられた固有の数値IDがあります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。

開始する前に:

  • ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。

  • ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (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 <username>:<pwd>@<email server> priority 1 secure tls 
    end 
  3. 環境変数を構成しますds_emailに管理者のメールアドレスを指定します。

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

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

高いCPU使用率の監視

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

  1. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMPが有効になっていない場合は、snmpサーバーマネージャ コマンド

    
    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@<server name or ip>/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

    copy ftp://username:password@<server name or ip>/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. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「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使用率の監視を続行してください。

異常な通話切断の監視

この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。  エラーカウントが前回の投票から 5 以上増えている場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド

    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 Edge ソフトウェア

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

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

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

問題をトラブルシューティングするための診断署名をインストールする

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

また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 別の DS 環境変数を構成するds_fsurl_prefixをCisco TACファイルサーバーパス (cxd.cisco.com) として入力し、診断データをアップロードします。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャー次に示すとおりです。 ファイル アップロード トークンは、添付ファイルを追加することができます。

    
    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
    end 

    例:

    
    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド

    
    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 Edge ソフトウェア

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

    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@<server name or ip>/DS_64224.xml bootflash: 
    copy ftp://username:password@<server name or ip>/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. を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「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

診断署名の実行を確認する

次のコマンドでは、コマンドの [状態] 列call-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間は、「実行中」に変更されます。 出力は次のとおりですCall-home 診断署名統計の表示診断署名が対象イベントを検出してアクションが実行されたかどうかを検証するための最適な方法です。 [Triggered/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

Call-home 診断署名統計の表示

DS ID

DS 名

トリガー済み/最大/アンインストール

平均実行時間(秒)

最長実行時間(秒)

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 コマンド出力などの重要な情報が含まれています。

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

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

call-home diagnostic-signature deinstall <DS ID> 

例:

call-home diagnostic-signature deinstall 64224 

 

展開で観察された問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。