Webex Calling トランクにローカルゲートウェイを設定するには、このタスクフローを使用します。 コマンドラインを使ってローカルゲートウェイ自体で手順を実行します。 ローカルゲートウェイと Webex Calling間のトランクは、ローカルゲートウェイと Webex Calling アクセス SBC の間のメディア用の SIP TLS トランスポートと SRTP を使用して常に保護されます。

始める前に

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • Control Hub でトランクを作成し、目的のロケーションにそれを割り当てます。

  • このドキュメントで提供される構成ガイドラインは、既存の音声設定がない専用のローカル ゲートウェイ プラットフォームが配置されていることを前提としています。 既存の PSTN ゲートウェイまたは CUBE エンタープライズ展開が、Webex Calling に対するローカル ゲートウェイ機能も使用するように変更されている場合、適用された構成に注意を払い、行った変更の結果として既存のコール フローと機能が中断されないようにしてください。

  コマンドまたはアクション 目的
1

Control Hub とCisco Unified Border Element 間のパラメーター マッピング

この表は、Control Hub からのパラメーターと、ローカル ゲートウェイにマッピングされる場所の参照として使用します。

2

参照プラットフォーム構成を実行する

これらの手順をローカル ゲートウェイの共通のグローバル構成として実装します。 構成には、ベースライン プラットフォーム構成と信頼プールの更新が含まれます。

3

ローカル ゲートウェイを Webex Calling に登録する

4

展開に応じて 1 つ選択します。

ローカル ゲートウェイ上の呼び出しルーティングは、選択した Webex Calling 展開オプションに基づいています。 このセクションでは、IP PSTN 終端がローカル ゲートウェイと同じプラットフォーム上にあることを前提としています。 次の設定は、ローカルゲート ウェイ上のこれらのオプションのいずれかです。

  • オンプレミス IP PBX なしのローカル ゲートウェイ展開オプション。 ローカル ゲートウェイと IP PSTN CUBE は共存しています。

  • 既存の Unified CM 環境内のローカル ゲートウェイ展開オプション。 ローカル ゲートウェイと IP PSTN CUBE は共存しています。

表 1. Control Hub とローカル ゲートウェイ間のパラメーター マッピング

Control Hub

ローカル ゲートウェイ

登録ドメイン:

Control Hub は、UCAPI から受信した LinePort からドメインを解析する必要があります。

example.com

registrar

example.com

トランク グループ OTG/DTG

sip profiles:

rule <rule-number> request ANY sip-header

From modify ">" ";otg=otgDtgId>"

回線/ポート

user@example.com

number: ユーザー

Outbound Proxy

outbound proxy (DNS name – SRV of the Access SBC)

SIP Username

username

SIP Password

password

始める前に

  • NTP、ACL、パスワードの有効化、プライマリ パスワード、IP ルーティング、IP アドレスなどのベースライン プラットフォーム構成が、組織のポリシーと手順に従って構成されていることを確認します。

  • すべての LGW 展開には、IOS-XE 16.12 または IOS-XE 17.3 のサポートされている最小バージョンが必要です。

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

資格情報と共有シークレットで使用する前に、以下のコマンドを使用してパスワードのプライマリキーを事前に構成する必要があります。 Type 6 パスワードは、AES 暗号化とユーザー定義のプライマリキーを使用して暗号化されます。


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes
3

IP ネーム サーバーを構成して DNS ルックアップを有効にし、ping で到達できることを確認します。


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

TLS 1.2 排他性とデフォルトのプレースホルダー Trustpoint の有効化:

  1. プレースホルダー PKI Trustpoint を作成して「sampleTP」という名前を付けます。

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

  3. Cn-san-validate server で設定されたアウトバウンド プロキシがローカル ゲートウェイで接続を確立することを保証するために必要です。 tenant 200 (後述) は、サーバーから受信した CN-SAN リストと一致します。

  4. 接続のセットアップにローカルクライアント証明書 (たとえば、mTLS) は必要ありませんが、TLS が機能するには暗号トラストポイントが必要です。

  5. V1.2 を排他的に有効化することで、TLS v1.0 および v1.1 を無効化します。

  6. tcp-retry カウントを 1000 (5 マイクロ秒の倍数 = 5 秒) に設定します。

  7. (IOS-XE 17.3.2 以降) タイマー接続を設定して tls <wait-timer in="" sec=""> を確立します。 範囲は 5 ~ 20 秒で、デフォルトは 20 秒です。 (LGW は次に利用可能な Webex Calling Access SBC への接続の確立を試みる前に、TLS 接続障害の検出に 20 秒かかっています。 この CLI では、管理者はネットワーク条件に対応し、Access SBC の接続障害をより早く検出できるように、値を変更することができます。


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

LocalGateway(config)#sip-ua
LocalGateway(config-sip-ua)# crypto signaling default trustpoint sampleTP cn-san-validate server

LocalGateway(config-sip-ua)# transport tcp tls v1.2
LocalGateway(config-sip-ua)# tcp-retry 1000
LocalGateway(config-sip-ua)#end
5

ローカル ゲートウェイ Trustpool の更新:

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

Trustpool バンドルは、最新の「Cisco Trusted Core Root Bundle」を http://www.cisco.com/security/pki/ からダウンロードすることにより、更新されなければなりません。

  1. DigiCert Room CA と IdenTrust Commercial の証明書が存在しているかどうか確認します。

    
    LocalGateway#show crypto pki trustpool | include DigiCert
  2. 存在しない場合は、以下のとおり更新します。

    
    LocalGateway#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    LocalGateway(config)#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.
    LocalGateway(config)#end
    
  1. 確認:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    
    LocalGateway#show crypto pki trustpool | include IdenTrust Commercial
    cn=IdenTrust Commercial Root CA 1
    cn=IdenTrust Commercial Root CA 1

始める前に

Control Hub の手順が完了しており、ロケーションを作成してそこにトランクを追加したことを確認します。 こちらの例では、情報が Control Hub から取得されています。

1

これらのコマンドを入力して、ローカル ゲートウェイ アプリケーションをオンにします 信頼できるリストにに追加する必要がある最新の IP サブネットについては、「Cisco Webex Calling のポート参照情報を」をご単ください):

LocalGateway#configure terminal
LocalGateway(config)#voice service voip
LocalGateway(conf-voi-serv)#ip address trusted list
LocalGateway(cfg-iptrust-list)#ipv4 x.x.x.x y.y.y.y
LocalGateway(cfg-iptrust-list)#exit
LocalGateway(conf-voi-serv)#allow-connections sip to sip
LocalGateway(conf-voi-serv)#media statistics
LocalGateway(conf-voi-serv)#media bulk-stats
LocalGateway(conf-voi-serv)#no supplementary-service sip refer
LocalGateway(conf-voi-serv)#no supplementary-service sip handle-replaces
LocalGateway(conf-voi-serv)# fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

LocalGateway(conf-serv-stun)#stun
LocalGateway(conf-serv-stun)#stun flowdata agent-id 1 boot-count 4
LocalGateway(conf-serv-stun)#stun flowdata shared-secret 0 Password123$

LocalGateway(conf-serv-stun)#sip

   LocalGateway(conf-serv-sip)#g729 annexb-all
   LocalGateway(conf-serv-sip)#early-offer forced
   LocalGateway(conf-serv-sip)#end

コマンドの説明:

不正料金の防止
Device(config)# voice service voip
Device(config-voi-serv)# ip address trusted list
Device(cfg-iptrust-list)# ipv4 x.x.x.x y.y.y.y
  • ローカル ゲートウェイが Webex Calling ピア、Unified CM ノード、IP PSTN などの正当な VoIP コールを期待するエンティティのソース IP アドレスを明示的に有効にします。

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

  • このリストの IP アドレスは、顧客が接続している地域の Webex Calling データ センターに応じて IP サブネットと一致する必要があります。 詳細については、「Webex Calling のポート参照情報」を参照してください。


     

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

  • 他のインターフェイスでは、他の IP アドレスを設定することが必要になる場合があります。たとえば、Unified CM アドレスを内向きのインターフェイスに追加する必要がある場合があります。

  • IP アドレスは、 outbound-proxyテナント 200 で解決されるホストの IP と一致している必要があります。

  • 詳細については、https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.htmlを参照してください。

メディア
voice service voip
 media statistics 
 media bulk-stats 
  • メディア統計は、ローカル ゲートウェイのメディア監視を有効にします。

  • メディア一括統計は、一括呼び出し統計のためのコントロール プレーンがデータプレーンをポーリングできるようにします。

SIP-to-SIP 基本機能
allow-connections sip to sip
補足サービス
 no supplementary-service sip refer
 no supplementary-service sip handle-replaces

REFER を無効にして、ピア ダイアログ ID の Replace ヘッダーでダイアログ ID を置換します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s12.html#wp2876138889を参照してください。

ファックス プロトコル
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

fac トラフィックは暗号化されませんが、fax トランスポートに対して T. 38 を有効にします。

Enable Global STUN
stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
  • コールが Webex Calling ユーザー(例: 着信側と発信側の両方が Webex Calling サブスクライバーであり、Webex Calling SBC でアンカーされているメディアを持っている)に転送されたとき、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

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

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

G729
sip
  g729 annexb-all

G729 のすべてのバリアントを許可します。

SIP
early-offer forced

ローカル ゲートウェイに、隣接ピアからの確認応答待知の代わりに、初期 INVITE メッセージで SDP 情報を送信するように強制します。

2

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

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

これらのルールは、以下のとおりです。

コマンドの説明:

  • rule 9 によってヘッダーが “SIP-Req-URI” としてリストされ、次のようにリストされなくなります: “SIP-Req-URL”

    これは、SIP URI と SIP URL の間で変換されます。Webex Calling はリクエスト/応答メッセージで SIP URI をサポートしていませんが、次のような SRV クエリに対してそれらを必要とするためです: _sips._tcp.<outbound-proxy>.
  • rule 20 は、From ヘッダーに Control Hub からの Trunk Group OTG/DTG パラメーターを含めて、エンタープライズ内の LGW サイトを固有に識別できるように変更します。

  • この SIP プロファイルは、Webex Calling 向けのすべてのトラフィックに対して voice class tenant 200(後で取り上げる)を適用します。

3

Codec プロファイル、STUN 定義、および SRTP Crypto スイートを設定します。

LocalGateway(config)# voice class codec 99
LocalGateway(config-class)# codec preference 1 g711ulaw
LocalGateway(config-class)# codec preference 2 g711alaw 
LocalGateway(config-class)# exit
LocalGateway(config)# voice class srtp-crypto 200
LocalGateway(config-class)# crypto 1 AES_CM_128_HMAC_SHA1_80
LocalGateway(config-class)# exit
LocalGateway(config)# voice class stun-usage 200
LocalGateway(config-class)# stun usage firewall-traversal flowdata
LocalGateway(config-class)# stun usage ice lite
LocalGateway(config-class)# exit

コマンドの説明:

  • Voice class codec 99: セッションに対して g711 (mu and a-law) コーデックを許可します。 すべてのダイヤルピアに適用されるls。

  • Voice class srtp-crypto 200: 要求と応答の SDP で ローカル ゲートウェイ で提供される唯一の SRTP 暗号スイートとして、SHA1_80 を指定します。 Webex Calling は SHA1_80 のみをサポートします。

  • Webex Calling 向けの voice class tenant 200 (後で取り上げる)に適用されます。

  • Voice class stun-usage 200: STUN の使用量を定義します。 Is は Unified CM が別の Webex Calling 電話に転送されるときに音声を回避するために、すべての Webex Calling 向きの (2XX タグ) ダイヤルピアに適用されます。


 

メディアが ITSP SBC で固定されており、ローカル ゲートウェイが NAT の背後で、ITSP からのインバウンド メディア ストリームを待っている場合、このコマンドはダイヤルピア向きの ITSP に適用されます。


 

メディアパスの最適化を利用した通話フローでは、Stun usage ice lite が必要です。

4

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

Webex Calling はローカル ゲートウェイ内のテナントとして追加されます。 ローカル ゲートウェイを登録する必要がある設定は、voice class tenant 200 の下で定義されます。 こちらの画像のように、Control Hub 内のトランク情報ページからその構成の要素を取得する必要があります。 これは、それぞれのローカル ゲートウェイ CLI にマップされるフィールドを表示している例です。

テナント 200 は、その後ローカル ゲートウェイ設定の中で、Webex Calling 向けのすべてのダイヤルピア (2xx タグ) に適用されます。 音声クラス テナント機能では、音声サービス voip と sip-ua の下で行われた SIP トランク パラメータのグループ化と設定が可能になります。 テナントがダイヤルピアの下で設定され、適用される場合、IOS-XE 設定は次の優先順位で適用されます。

  • ダイヤルピア設定

  • テナント構成

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

5

音声クラス テナント 200 を構成し、Control Hub から取得したパラメータに基づいて、LGW から Webex Calling へのトランク登録を有効にします。


 

以下のコマンド ラインとパラメータは、例のみです。 独自の展開でパラメータを使用する必要があります。

LocalGateway(config)#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

コマンドの説明:

voice class tenant 200

ローカル ゲートウェイのマルチテナント機能により、テナントに対して差別化されたサービスに許可される SIP トランクの複数のテナントの特定のグローバル設定が有効になります。

registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls

2 分 (240 秒の50%) ごとに更新するように登録が設定されたローカル ゲートウェイのレジストラ サーバー。 詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-r1.html#wp1687622014 を参照してください。

credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks

トランク登録チャレンジの資格情報。 詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c6.html#wp3153621104 を参照してください。

authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks
authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm 40462196.cisco-bcld.com

コールの認証の課題。 詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462 を参照してください。

no remote-party-id

Webex Calling は PAI をサポートしているため、CIO asserted-id pai を使って有効化されている SIP Remote-Party-ID(RPID)ヘッダーを無効にします(以下を参照)。

sip-server dns:40462196.cisco-bcld.com
Webex Calling サーバー 詳細については、次のサイトを参照してください。 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462
connection-reuse

登録とコール処理に対して同じ持続的な接続を使用するため。

srtp-crypto 200

次で定義されているように SHA1_80 を指定します。 voice class srtp-crypto 200.

session transport tcp tls
Sets transport to TLS
url sips

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

error-passthru

SIP エラー応答パススルー機能

asserted-id pai

ローカル ゲートウェイで PAI 処理をオンにします。

bind control source-interface GigabitEthernet0/0/1

Webex Calling に向けたシグナリング ソース インターフェイス。

bind media source-interface GigabitEthernet0/0/1

メディア ソース インターフェイスは Webex Calling に向いています。

no pass-thru content custom-sdp

テナントの下のデフォルト コマンド。

sip-profiles 200

SIPS を SIP に変更し、次で定義されているように、INVITE および REGISTER メッセージの回線/ポートを修正します: voice class sip-profiles 200.

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

Webex Calling Access SBC。 詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-o1.html#wp3297755699 を参照してください。

privacy-policy passthru

着信レッグから発信レッグにプライバシー ヘッダー値を透過的に通過します。

tenant 200 がローカル ゲートウェイ内で定義され、SIP VoIP ダイアルピヤが設定された後、ゲートウェイは Webex Calling に向けて TLS 接続を開始し、その時点で Access SBC はその証明書をローカル ゲートウェイに提示します。 ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling Access SBC 証明書を検証します。 持続的な TLS セッションは、ローカル ゲートウェイと Webex Calling Access SBC の間で確立されます。 ローカル ゲートウェイはその後、課題となる Access SBC に REGISTER を送信します。 登録 AOR は number@domain です。 番号は資格情報の「number」パラメーターから取得され、ドメインは「registrar dns:<fqdn>」から取得されます。 登録がチャレンジされると、資格情報ユーザー名、パスワード、および領域パラメーターはヘッダーを構築するために使用され、sip-profile 200 は SIPS URL を SIP に変換します。 Access SBC から 200 OK を受け取ると、登録は正常に行われたことになります。

ローカル ゲートウェイでの次の設定は、展開のオプションに必要です。

  1. 音声クラス テナント — 最初に、ダイヤルピアに面した Webex Calling に対して作成されたtenant 200と同様に、ITSP に面しているダイヤルピアの追加テナントを作成する必要があります。

  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. コントロール ハブの TrunkGroup 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
    

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

    このダイヤルピアが 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

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 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

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

    session target sip-server

    グローバル SIP サーバーがこのダイヤルピアからのコールの宛先であることを示します。 tenant 200 で定義されている Webex Calling サーバーは、このダイヤルピアに継承されます。

    voice-class stun-usage 200

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

    no voice-class sip localhost

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

    voice-class sip tenant 200

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 200 (LGW <--> Webex Calling Trunk) からすべてのパラメータ継承します。

    srtp

    SRTP は、このコール レッグに対して有効になっています。

    no vad

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

4

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

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

    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

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

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    incoming uri via 100

    IP PSTN から LocalGW へのすべての着信トラフィックは、音声クラス URI 100 SIP で定義されたヘッダーのホスト IP アドレス経由の着信とソース IP (ITSP) アドレスに基づいて照合されます。

    destination dpg 200

    宛先 dpg 200 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先ダイヤルピア グループ 200 (ダイヤルピア 200201) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class sip tenant 300

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 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

    タグ 200201 で VOIP ダイヤルピアを更新し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    incoming uri request 200

    Webex Calling から LGW へのすべての着信トラフィックは、リクエスト URI の一意の dtg パターンで一致し、エンタープライズ(アカウント)内および Webex Calling エコシステム内のローカル ゲートウェイ サイトを固有に識別します。

    destination dpg 100

    宛先 dpg 100 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先ダイヤルピア グループ 100 (ダイヤルピア 101) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    max-conn 250

    本ガイドで定義されているとおり、着信と発信の両方の Webex Calling に対して 1 つのダイヤル ピアがあると想定して、同時通話の数を LGW と Webex Calling の間で 250 に制限します。 ローカル ゲートウェイに関連する同時通話の制限の詳細については、https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf を参照してください。

PSTN から Webex Calling

ローカル ゲートウェイ のすべての着信 IP PSTN コール レッグは、IP PSTN の IP アドレスを持つ VIA ヘッダーのマッチング基準を定義するため、ダイヤルピア 100 でマッチングします。 発信ダイヤルピアの選択は、発信ダイヤルピア 200201 を直接呼び出す DPG 200 によって指示され、ターゲット宛先として Webex Calling サーバーがリストされています。

Webex Calling から PSTN

ローカル ゲートウェイ のすべての Webex Calling コール レッグの着信は、このローカル ゲートウェイ展開に固有の TrunkGroup OTG / DTG パラメータを使用して REQUEST URI ヘッダー パターンのマッチング基準を満たしているため、ダイヤルピア 200201 でマッチングします。 発信ダイヤルピアの選択は、発信ダイヤルピア 101 を直接呼び出す DPG 100 によって指示され、それは、ターゲット宛先として IP PSTN IP アドレスがリストされています。

この展開オプションの場合、ローカル ゲートウェイの以下の設定が必要です。

  1. 音声クラス テナント—ダイヤルピアに面した Webex Calling に対して作成された tenant 200 と同様に、Unified CM および ITSP に面しているダイヤルピアの追加テナントを作成する必要があります。

  2. 音声クラス URI—LGW で終端するさまざまなトランクのためのホスト IP アドレス/ポートを定義するパターン: PSTN 宛先に対する Unified CM から LGW、Webex Calling 宛先に対する Unified CM から LGW、Webex Calling から LGW、および LGW で PSTN SIP トランク終端。

  3. 音声クラス サーバー グループ—LGW から Unified CM、LGW から Webex Calling 、LGW から PSTN SIP トランクの送信トランクの宛先 IP アドレス/ポート。

  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. コントロール ハブの TrunkGroup 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 トランクの CUCM ソースシグナリング IP と VIA ポートを定義します。

    voice class uri 302 sip
     pattern 192.168.80.60:5060
    
3

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

  1. Unified CM トランクのターゲット ホスト IP アドレスと Unified CM Group 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 Group 1 のポート番号を定義します。

    voice class server-group 303
     ipv4 192.168.80.60 port 5065
    
  3. Unified CM Group 1 (5 ノード) に対する 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 Group 2 に対する 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

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    session target ipv4:192.168.80.13

    このコール レッグが発信される宛先の Ipv4 アドレスを示します。(この場合は ITSP の IP アドレス。)

    voice-class codec 99

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

    voice-class sip tenant 100

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 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

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

    session target sip-server

    グローバル SIP サーバーがこのダイヤルピアからのコールの宛先であることを示します。 tenant 200 で定義されている Webex Calling サーバーは、このダイヤルピアに継承されます。

    voice-class stun-usage 200

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

    no voice-class sip localhost

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

    voice-class sip tenant 200

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 200 (LGW <--> Webex Calling Trunk) からすべてのパラメータ継承します。

    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
     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

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

    session server-group 301

    ダイヤルピアのセッション ターゲット IP の代わりに、宛先サーバー グループをポイントし (ダイヤルピア 301 の サーバーグループ 301)、サンプルを通じて複数のターゲット UCM ノードを定義する場合は、シングルノードのみを表示します。

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

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

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.htmlを参照してください。

  4. 5 つ以上の Unified CM ノードをもつ場合に、Unified CM の Webex Calling Trunk に向かう 2 番目の送信ダイヤルピア。

    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
     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-1 
    for inbound from PSTN - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 305
     voice-class codec 99 
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
  6. 5 つ以上の Unified CM ノードをもつ場合に、Unified CM の PSTN Trunk に向かう 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  
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
5

以下の DPG を構成します。

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

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

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

    voice class dpg 300
     dial-peer 301 preference 1
     dial-peer 303 preference 1
    
  4. 発信ダイアル ピア DPG 305 または 307 に対する 302PSTN --> 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

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

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    incoming uri via 100

    IP PSTN から LGW へのすべての着信トラフィックは、音声クラス URI 100 SIP で定義されたヘッダーのホスト IP アドレス経由の着信とソース IP (ITSP) アドレスに基づいて照合されます。

    destination dpg 302

    宛先 DPG 302 では、IOS-XE は従来の送信ダイヤルピア マッチング基準に合格し、すぐに宛先 DLG 302(ダイヤルピア 305 またはダイアルピア 307 のいずれか) 内で定義されたダイヤルピアを使用して送信コールレッグをセットアップします。

    voice-class sip tenant 300

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 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

    タグ 200201 で VOIP ダイヤルピアを更新し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    incoming uri request 200

    Webex Calling から LGW へのすべての着信トラフィックは、リクエスト URI の一意の dtg パターンで照合でき、エンタープライズ内および Webex Calling エコシステム内のローカルゲートウェイサイトを一意に識別します。

    destination dpg 300

    宛先 DPG 300 では、IOS-XE は従来の送信ダイヤルピア マッチング基準に合格し、すぐに宛先 DLG 300(ダイヤルピア 301 またはダイアルピア 303 のいずれか) 内で定義されたダイヤルピアを使用して送信コールレッグをセットアップします。

    max-conn 250

    本ガイドで定義されているとおり、着信と発信の両方の Webex Calling に対して 1 つのダイヤル ピアがあると想定して、同時通話の数を LGW と Webex Calling の間で 250 に制限します。 ローカル ゲートウェイに関連する同時通話の制限の詳細については、https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf を参照してください。

  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

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

    incoming uri via 300

    Unified CM から LGW へのすべての着信トラフィックは、音声クラス URI 300 SIP で定義された VIA ソース ポート (5065)で照合されます。

    destination dpg 200

    宛先 DPG 200 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先 DPG 200 (ダイヤルピア 200201) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class sip tenant 300

    同じパラメータがダイヤルピア自体の下で定義されていない限り、ダイヤルピアは Tenant 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

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

    incoming uri via 302

    PSTN 宛先に対する Unified CM から LGW へのすべての着信トラフィックは、Unified CM ソース シグナル IP アドレス、および音声クラス URI 302 SIP で定義された VIA ソース ポート (5065)で照合されます。 標準 SIP ポート 5060 が使用されます。

    destination dpg 100

    宛先 DPG 100 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先 DPG 100 (ダイヤルピア 101) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class sip tenant 300

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

IP PSTN to Unified CM PSTN Trunk

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

IP PSTN への Unified CM PSTN Trunk to IP PSTN

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

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

診断署名(DS)は、問題をトリガーしたイベントおよび問題を通知、トラブルシューティング、修正するために実行されるアクションに関する情報を含む XML ファイルです。 問題検出ロジックは、syslog メッセージ、SNMP イベント、特定の show コマンド出力の定期的な監視によって定義されます。 アクションタイプには、show コマンド出力の収集、統合ログファイルの生成、ユーザーが指定したネットワークロケーション(HTTPS、SCP、FTP サーバーなど)へのアップロードが含まれます。 DS ファイルは TAC エンジニアにより作成され、デジタル署名によって整合性が維持されます。 各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。 Diagnostic Signatures Lookup Tool(DSLT)は、さまざまな問題を監視およびトラブルシューティングするのに適切な署名を見つけ出すための唯一の情報源です。

開始する前に:

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

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

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

前提条件

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

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

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

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    LocalGateway(config)#end 
  3. 通知を受け取る管理者のメールアドレスで環境変数 ds_email を構成します。

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

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

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

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

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

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

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

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

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

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

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

以下は、IOS XE 17.3.2 を実行して、Gmail をセキュアな SMTP サーバーとして使用する tacfaststart@gmail.com にプロアクティブ通知を送信するローカルゲートウェイの構成サンプルです。


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

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. コマンド show snmp を使用して、SNMP が有効になっていることを確認します。 有効になっていない場合は、「snmp-server manager」コマンドを構成してください。

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
    
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
    
    LocalGateway# 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 
    .... 
    .... 
    LocalGateway# 
  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

    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 サーバーからローカルゲートウェイにファイルをコピーする例を示しています。

    
    LocalGateway# 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) 
    LocalGateway # 
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

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

    
    LocalGateway# 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

    LocalGateway#


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

SIP トランク登録の監視

この DS は、Cisco 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 ファイルをローカルゲートウェイにコピーします。

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

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

異常な通話切断の監視

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

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

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
    
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
    
    LocalGateway# 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 
    .... 
    .... 
    LocalGateway# 
  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

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

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

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

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

特定の問題を自分で解決するために、Diagnostic Signatures Lookup Tool を使用して、適切な署名を見つけてインストールすることができます。また、TAC エンジニアがサポートの一部として推奨する署名をインストールすることもできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下の手順を使って診断データ収集を自動化する DS の見つけ方とインストール方法を示したものです。

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

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
    LocalGateway(config)#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」コマンドを構成してください。

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
     
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
  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 ファイルをローカルゲートウェイにコピーします。

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

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

    
    LocalGateway# 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

    LocalGateway#

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

以下に示すように、コマンド show call-home diagnostic-signature の [Status] 列が [running] に変わる一方で、ローカルゲートウェイでは署名内で定義されたアクションが実行されています。 show call-home diagnostic-signature statistics の出力は、診断署名が対象イベントを検出してアクションを実行したかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出回数が最大に達した後に署名が自動的にアンインストールされるどうかが表示されます。


LocalGateway# 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

LocalGateway#

LocalGateway# show call-home diagnostic-signature statistics

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

LocalGateway#

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

診断署名のアンインストール

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


LocalGateway# call-home diagnostic-signature deinstall <DS ID> 
LocalGateway# 

例:


LocalGateway# call-home diagnostic-signature deinstall 64224 
LocalGateway# 

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