コメントありがとうございます。

パートナーが採用できるさまざまな導入モデルを説明するために、TelSP という名前の架空の Webex パートナーを考えてみましょう。

TelSPの大まかな仕様と要件は次のとおりです。

• パートナーは、管理するすべての顧客に共有される最上位ドメインとしてsip.telsp.comを使用する予定です。

• パートナーはsip.telsp.comを所有しており、DNSインフラストラクチャと認証局の管理、DNSアドレスの管理、このドメインとそのサブドメインの証明書への署名を行うことができます。

• パートナーは、エンドカスタマー間の共有PSTNアクセス用のローカルゲートウェイとして、2つの異なるセッションボーダーコントローラー（物理または仮想）を導入できます。

• パートナーには2つの物理サイトがあり、どちらのサイトもPSTN接続を共有しています。

  • マイアミ

  • シカゴです

• TelSPは、ここで言うCuSTAとCustBの2人の顧客に代わってローカルゲートウェイを運用しています。

望ましいシナリオは、図に示すように、パートナーが提供するマイアミとシカゴのゲートウェイを使用する両方の顧客に対してPSTNの発信/終了を行うことです。

簡略化された導入例

次の簡単な例は、 ピア証明書IDによって1つの証明書で複数の顧客トランクをサポートする方法を示しています。

• 証明書 —sip.telsp.com

• トランクス

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• ピア証明書アイデンティティ —sip.telsp.com

• 結果

  • 単一の証明書が使用されています

  • 複数の顧客トランクがサポートされています

顧客の所在地をトランクとゲートウェイに関連付ける

次のセクションでは、 上記のデプロイメントの詳細な構成マッピングについて説明します。

Webex Callingトランクを作成し、 複数の場所でトランクを共有することができます。 トランクを作成するときは、 トランクを場所に関連付けてください。

CuSTAの場合、トランクの詳細は次のとおりです。

この図は、 顧客の所在地とCuSTAのゲートウェイとトランクとの関連付けを示しています。

この展開では、 ロケーションに関連するトランクがそのロケーションのプライマリPSTN接続です。 もう一方のトランクは、 特定のダイヤルプランエントリのセカンダリPSTN接続またはルートとして使用されます。 プライマリとセカンダリのPSTN接続関係の実装は、ルートグループの概念によるものです。 詳細については、「 コントロールハブのゲートウェイトランクの設定」セクションを参照してください。

CustBの場合、 次のトランクを使用して同様の設定が作成されます。

この図は、 顧客の所在地とCustBのゲートウェイとトランクとの関連付けを示しています。

この図は、 ニューヨークという3番目の場所を示しています。後で追加して、 プライマリPSTN接続としてtrunk_chicagoトランクを指すことができます。

複数のトランクを共有するローカルゲートウェイを導入する場合、 シスコはトランクごとに固有のFQDNを使用することを義務付けています。 詳細については、「トランクの設定」、「ルートグループ」、および「WebEx 通話のダイヤルプラン」を参照してください。

IPアドレスとトランクごとに既知のポートを使用するのが理想的な選択です。 ただし、サイトごとにゲートウェイごとに1つのアドレスを使用したい一部のパートナーにとって、パブリックIPv4アドレスの調達は難しい場合があります。

したがって、次の重要な指針を読んでください。

• シスコはトランクごとにIPアドレスを義務付けていません。

• トランクアドレスは、固有のIPアドレスまたは別のトランク間で共有されるアドレスに変換できます。

• シスコでは、次の理由から、 ローカルゲートウェイ上で各トランク接続に固有のIPアドレスとポートの組み合わせを設定することを推奨しています。

  1. トランクごとに個別のTCP接続リンクを維持することで、 トランクあたりの最大同時通話容量をサポートします。 トランク間でIPアドレスとポートの組み合わせを共有すると、 通話容量に悪影響を及ぼす可能性があります。

  2. 顧客間のネットワークレベルの分離を提供します

  3. IPアドレスで区切られた一意のテナントまたはテナント固有のリッスンポートとして分離されていない限り、セッションボーダーコントローラーでは一時的なTCPソケット接続を再利用するのが一般的です。

  4. テナント分離によるトランクあたりの接続数または接続数により、特にデータ損失の多いネットワーク条件でスループットが向上します。 したがって、ある顧客からのトラフィックが他の顧客には影響しません。

ゲートウェイごとのIPアドレス：トランクの構成と推奨事項

計画には、次のさまざまなモデルの例を参照してください。

モデル1：トランクごとの固有のIPアドレス

このモデルでは、両方のゲートウェイでホストされるすべてのトランクが一意のIPアドレスに割り当てられ、これらの各トランクは同じポートを使用する場合と使用しない場合がありますが、理想的には同じポートを使用します。

情報を表形式で表す：

同じモデルでは、パートナーはSRVアドレスを使用できます。 Webex Calling「_sips」のみを許可します。ピアアドレスがSRVレコードの場合は、サービスとプロトコルの組み合わせとして「_tcp」を指定します。

SRVレコードがどのように解決されるかのサンプル

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

モデル2：ゲートウェイごとの共有IP、固有のリッスンポート

このモデルでは、シカゴのローカルゲートウェイでホストされているすべてのトランクは同じIPアドレスに解決され、マイアミのローカルゲートウェイにホストされているすべてのトランクは別のIPアドレスに解決されます。 ただし、同じIPを使用する場合、各トランクはコントロールハブのFQDNを使用して構成され、固有のポートで構成されます。

同じモデルで、パートナーはSRVアドレスを使用しています。 Webex Calling「_sips」のみを許可します。ピアアドレスがSRVレコードの場合は、サービスとプロトコルの組み合わせとして「_tcp」を指定します。

SRVレコードがどのように解決されるかの別の例は次のとおりです。 この例では、 IPアドレスごとに1つのAレコードが存在します。 ただし、ポートはアドレスごとに異なり、 SRVアドレスを適切なポートにリンクする特定のDNS設定によって表されます。

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

SRVベースのトランクの場合、 ピア証明書のIDは最初に設定済みのSRV値から入力され、同じ検証ルールに従ってカスタマイズできます。

パートナーはtelsp.comとそのサブドメインを所有しています。 したがって、 DNSサーバーと承認された認証局によって署名された証明書を取得する権限はパートナーにあります。

• Cisco Webex パートナーがAレコードを含むFQDNまたはSRVアドレスをパブリックドメインで公開することを期待しています。

• Cisco Webex パートナーがこの文書に記載されている認証局のいずれかを使用することを期待しています。

FQDNまたはSRVを使用してトランクを設定する場合：

• ルーティングと識別のために、各トランクにはまだ固有のFQDNが必要です

• DNSレコード（AレコードまたはSRV）は正しく設定され、解決可能でなければなりません

• これらのFQDNはシグナリングとルーティングに使用されます。 証明書の検証は、 設定されたピア証明書IDに対して実行されます。デフォルトはトランクのFQDN値ですが、 パートナーが所有する共有IDにカスタマイズできます。

  ピア証明書のIDフィールドはトランクのFQDNから事前に入力されており、 パートナーが所有する共有ドメインでオーバーライドして、複数の顧客トランクで1つの証明書を使用できます。

ゲートウェイをセットアップします

これらのリソースを使用して、ローカルゲートウェイを設定してください。

Cisco CUBEを設定するには、次の手順に従ってください。Cisco IOS XEのローカルゲートウェイを次のように設定します Webex Calling

承認されたサードパーティのSBCを設定できます。「ローカルゲートウェイを始めよう」を参照してください。

次のガイドラインに従って、パートナーがホストするゲートウェイを設定します。ローカルゲートウェイを始めましょう

SBCデバイスの関連指示に従って各トランクを設定してください。 Cisco CUBEの手順については、「Cisco IOSXEでのローカルゲートウェイの設定」を参照してください Webex Calling

画像に従って、トランクの着信トラフィックと発信トラフィックの音声クラス、ダイヤルピア、ダイヤルピアグループを設定します。

トランクをプロビジョニングする際、Control Hubの「トランクの追加」 ページにピア証明書IDを設定するオプションが表示されます。 この機能強化により、 パートナーは単一の最上位ドメインを構成して複数の顧客組織で再利用できるようになり、 ワークフローが簡素化されます。 このアプローチにより、 顧客またはトランクごとに個別の証明書を用意する必要がなくなり、運用上の労力が軽減され、 セットアッププロセスが簡単になります。

Control Hubでトランクを設定するときは、 ピア証明書IDを定義して、すべての顧客組織の最上位ドメインで単一の証明書を使用できるようにします。 証明書のCNまたはSANにこの最上位ドメインが含まれていることを確認してください。 ピア証明書IDでは、ローカルゲートウェイは、 CNまたはSANにパートナーの共有ドメイン（sip.telsp.comなど）を含む単一の証明書を使用します。 ワイルドカード証明書（ *.sip.telsp.comなど）はサポートされていません。 Webex Calling ピア証明書IDとしてその値を明示的に設定したすべての顧客トランクでこの証明書を受け入れます。 証明書には、 CNまたはSANに正確に設定されたピア証明書のID値が含まれている必要があります。 これにより、個々のトランク FQDN に個別の証明書や CN/SAN エントリを設定する必要がなくなります。

ドメイン検証と証明書の使用方法

ドメイン認証と証明書の使用の違いを理解することが重要です。

• ドメイン検証（お客様ごと）—各顧客組織は、 DNSに固有のTXTレコードを追加して、ドメイン（sip.telsp.comなど） を個別に検証する必要があります。 これにより、パートナーがドメインを所有し、 不正使用を防ぐことができます。

• 証明書管理（グローバル） —パートナーの最上位ドメイン用に発行された1つの証明書を、ピア証明書IDを使用してすべての顧客トランクで共有できます。 顧客ごとまたはトランクごとに個別の証明書を管理する必要はありません。

ピア証明書のアイデンティティ行動

ピア証明書IDは、Webex Callingローカルゲートウェイによって提示される証明書に期待されるIDを定義します。

設定すると：

• Webex Calling 設定されたピア証明書のIDを証明書のCNまたはSANと照合して証明書を検証します

• 値が一致すれば、TLS接続は受け入れられます

• 値が一致しない場合、接続は拒否されます

ピア証明書IDが一致して明示的に設定されたトランクだけが認証できます 。

認証中に行われるチェックは、証明書の検証だけではありません。 Webex Calling証明書CNまたはSANを設定済みのピア証明書IDと照合して検証するだけでなく、トランクFQDNが明示的に設定され、Control Hubで一致するピア証明書IDに関連付けられていることも確認します。

ピア証明書のIDは、トランクのFQDN/SRV値から事前に入力されています。 デフォルトのままにしておけば、既存のトランクごとの証明書の動作は変わりません。 既存の証明書ベースのトランクは、変更しなくても引き続き機能します。 新しいトランクまたは既存のトランクに共有のピア証明書IDを自分のペースで採用でき、両方のモデルを共存させることができます。

1. 有効な設定例：

   • 証明書 CN —sip.telsp.com

   • 証明書SAN —custa.sip.telsp.com

   • ピア証明書アイデンティティ —custa.sip.telsp.com

   • トランク FQDN —trunk.miami.custa.sip.telsp.com

   結果-ピア証明書のアイデンティティ （custa.sip.telsp.com）が証明書のSAN値と一致し、トランクのFQDN （trunk.miami.custa.sip.telsp.com）が設定されたピア証明書アイデンティティのサブドメインであるため、接続は成功します。

2. 接続障害の例：

   • 証明書 CN —sip.telsp.com

   • 証明書SAN —custa.sip.telsp.com

   • ピア証明書アイデンティティ —custb.sip.telsp.com

   • トランク FQDN —trunk.miami.custb.sip.telsp.com

   結果 — ピア証明書のアイデンティティ (custb.sip.telsp.com) が証明書のCNまたはSANに存在しないため、TLSハンドシェイク時に接続が失敗します。 トランクのFQDNは正しくピア証明書IDのサブドメインですが、証明書にはそのIDは含まれていません。

3. 無効な設定例:

   • 証明書 CN —sip.telsp.com

   • 証明書SAN —custa.sip.telsp.com

   • ピア証明書アイデンティティ —custa.sip.telsp.com

   • トランク FQDN —trunk.miami.custb.sip.telsp.com

   結果： トランクのFQDN（trunk.miami.custb.sip.telsp.com）が、設定されたピア証明書ID（custa.sip.telsp.com）と等しくないか、そのサブドメインではないため、コントロールハブは保存時にこの構成を拒否します。

パートナーハブから、CuSTAまたはCustBのコントロールハブを起動し、 ゲートウェイを設定できます。 この手順を使用して、お客様ごとに構成してください：

1. トランクの作成-各パートナー共有ゲートウェイの [通話]、[通話ルーティング]、[トランク] の下にトランクを追加します。 トランクを設定するには、「トランク、ルートグループ、ダイヤルプランの設定」を参照してください Webex Calling

2. ドメインを追加して確認—管理/組織設定/ドメインで、 トランクの作成に使用される次のドメインを追加して確認します。

   顧客B	顧客 C
   sip.telsp.com	sip.telsp.com

   ドメインを追加すると、トークンが生成され、パートナーのDNSサーバーのドメインのTXTレコードに配置されます。 このレコードにより、Control Hubはドメインがパートナーによって所有されていることを確認できます。 詳しくは、「ドメインを管理する」を参照してください

   共通ドメインは、各顧客の検証に使用されます。 ただし、 この検証は顧客組織レベルで行われるため、顧客組織ごとに異なるトークンを生成して検証に使用するようにしてください。 なぜなら、 顧客組織全体で単一のドメインが使用されているため、同じドメインを共有している場合でも、 各顧客組織は固有のTXTレコードを使用してドメインを個別に検証する必要があるからです。

   ピア証明書の身元確認にはドメイン認証のみが必要です。 共有ドメインを顧客組織に申請しないでください。 1つのドメインは1つの組織のみが申請できますが、同じドメインは複数の組織で検証できます。

3. FQDNでSBCアドレスを設定してください—

   マイアミゲートウェイの場合：

   パラメーター	顧客B	顧客 C
   場所	デンバー	ボストン
   トランク名	トランク_マイアミ	トランク_マイアミ
   トランクの種類	証明書ベース	証明書ベース
   デバイスタイプ	例えば Cisco Unified Border Element(またはサポートされている別のデバイス)	例えば Cisco Unified Border Element(またはサポートされている別のデバイス)
   SBC アドレスタイプ	FQDN	FQDN
   ホスト名	LGW. マイアミ	LGW. マイアミ
   ドメイン	sip.telsp.com	sip.telsp.com
   ポート	5061	5062
   FQDN	LGW.miami.customerb.sip.telsp.com: 5061	LGW.miami.customerc.sip.telsp.com: 5062
   同時通話の最大数（250-6500）	500	500

   シカゴゲートウェイの場合：

   パラメーター	顧客B	顧客 C
   場所	デトロイトです	ダラス
   トランク名	トランク_シカゴ	トランク_シカゴ
   トランクの種類	証明書ベース	証明書ベース
   デバイスタイプ	例えば Cisco Unified Border Element(またはサポートされている別のデバイス)	例えば Cisco Unified Border Element(またはサポートされている別のデバイス)
   SBC アドレスタイプ	FQDN	FQDN
   ホスト名	LGW. シカゴ	LGW. シカゴ
   ドメイン	sip.telsp.com	sip.telsp.com
   ポート	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com: 5061	lgw.chicago.customerc.sip.telsp.com: 5062
   同時通話の最大数（250-6500）	500	500

   • （オプション）トランク名は顧客組織全体で一意である必要はありません。 同じ名前（たとえば、trunk_miami）を再利用すると、トランクの追跡が容易になります。

   • 特定のSBCでは同じポートを設定できますが、 この構成は容量に影響を与える可能性があります。 そのため、別のポートを使用してください。

4. ピア証明書の身分証明書—

   • プレフィックス —プレフィックスはオプションです。 ピア証明書のIDをドメインのみに設定するには、空のままにしてください。 これは、この記事で使われている共有証明書モデルです（ ピア証明書ID—sip.telsp.com、すべての顧客トランクを網羅しています）。 オプションで、 より具体的な証明書IDを定義するプレフィックスを入力します（たとえば、顧客ごとの証明書の場合は、プレフィックス： CustomerB、ドメイン：Customerb.sip.Telsp.com）。 トランクのFQDN自体は、SBCアドレス、ホスト名、ドメインフィールドで定義されるままで、生成されるピア証明書IDと同じか、 サブドメインでなければなりません。

     例:

     プレフィックス — 顧客 B

     ドメイン — SIP.Telsp.com

     結果 — Customerb.sip.telsp.com

   • ドメイン: お客様の組織で確認されたドメインのリストからドメインを選択します。 生成されるピア証明書のID（プレフィックス+ドメイン）は、 SBCが提示する証明書のCNまたはSANと一致する必要があります。 Webex Callingこの値を使用してTLS接続を認証します。

     

     Control Hubは、トランクのFQDNが設定されたピア証明書IDの下にないため、 保存時にこの構成を拒否します。

     ピア証明書のIDが、 SBCが提示した証明書のCNまたはSANと一致しない場合、Webex Calling TLS接続を拒否し、トランクの確立に失敗します。

5. トランクの使い方—次の理由から、トランクの場所を自由に選択してください。

   • PSTN接続では、どの場所でもトランクを使用できます。

   • トランクにはルートグループを介してアクセスできます。

   • どのダイヤルプランでもトランクを使用できます。

6. トランクの定義と関連する場所を参照してください：

   

   これらのトランクを使ってルートグループを作成できます。 画像では、プライマリオプションとしてtrunk_miami_chicagoトランクにコールをルーティングし、 セカンダリオプションとしてtrunk_chicagoトランクにコールをルーティングするルートグループrg_miami_chicagoが定義されています。

   

   プライマリオプションとして trunk_chicago トランクに、セカンダリオプションとして trunk_miamiトランクにコールをルーティングする2番目のルートグループrg_chicago_miamiを定義できます。

7. 定義したトランクとルートグループが、各ロケーションのCalling Connection PSTNオプションで利用できるようになりました。 画像では、 デンバーの場所を参照してください。

   

8. ダイヤルプラン定義でトランクとルートグループを使用できます。 たとえば、 シカゴのお客様のオンプレミス番号範囲は、 画像内のrg_chicago_miamiルートグループ（すべての場所）に分割されています。

   

   

APIによる大規模なプロビジョニング

多数の顧客組織を管理しているパートナーは、 UIの代わりにAPIを使用してドメインを大規模にプロビジョニングできます。

• ドメインを確認

• 通話ルーティング