Cisco Meeting Server および Skype for Business の設定
内容
概要
このドキュメントでは、公式ガイドの一部として、Skype for BusinessでCisco Meeting Server(CMS)CallBridgeクラスタを設定する方法について説明します。このドキュメントでは、単一のCallBridgeの例と3つのCallBridgeクラスタの別の例を示しますが、必要に応じて追加のCallBridgeを追加できます。2つのCallBridgeクラスタもサポートされています。
著者：Cisco TACエンジニア、Rogelio Galindo、編集：Viridiana Fuentes
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Meeting Server(CMS)
- ドメイン ネーム サーバ（DNS）
- Skype For Business
- アプリケーションプログラミングインターフェイス(API)
使用するコンポーネント
- 3 CallBridgeクラスタを実行するCMSサーバ、ソフトウェアバージョン2.2.2。
- Skype for Business 2015
- Active Directory(AD)Windows Server 2012
- セキュアシェル(SSH)クライアント
- Secure File Transfer Protocol(SFTP)クライアント（WinSCPなど）
- PostmanなどのAPIプログラム
- Active Directory、DNS、およびSkypeサーバのリモートデスクトップセッション
ネットワークトポロジ：単一のCallBridge
ネットワークトポロジ – クラスタ化されたCallBridge
Callbridge証明書の要件：単一のCallBridge
表1aに、単一のCallBridge環境のCallBridge証明書の例を示します。
表1a
| CallBridge証明書 | 説明 |
| 単一のCallBridge | |
| CN:cms.uc.local | CallBridge FQDN |
Callbridge証明書の要件：クラスタ化CallBridge
表1bに、クラスタ化されたCallBridge環境のCallBridge証明書の例を示します。1つの証明書をクラスタ内のCallBridge間で共有できます。
表1b
| Callbridge証明書 | 説明 |
| [Server 1]：cms1.uc.local | |
| CN:cms.uc.local | CallBridgeクラスタのFQDN。このレコードは、すべてのCallBridgeクラスタピアに解決される必要があります。 |
| SAN:cms.uc.local | CallBridgeクラスタのFQDN。このレコードは、すべてのCallBridgeクラスタピアに解決される必要があります。 |
| SAN:cms1.uc.local | CallBridge 1 FQDN。 |
| SAN:cms2.uc.local | CallBridge 2 FQDN。 |
| SAN:cms3.uc.local | CallBridge 3 FQDN。 |
| [Server 2]：cms2.uc.local |
|
| CN:cms.uc.local | CallBridgeクラスタのFQDN。このレコードは、すべてのCallBridgeクラスタピアに解決される必要があります。 |
| SAN:cms.uc.local | CallBridgeクラスタのFQDN。このレコードは、すべてのCallBridgeクラスタピアに解決される必要があります。 |
| SAN:cms1.uc.local | CallBridge 1 FQDN。 |
| SAN:cms2.uc.local | CallBridge 2 FQDN。 |
| SAN:cms3.uc.local | CallBridge 3 FQDN。 |
| [Server 3]：cms3.uc.local | |
| CN:cms.uc.local | CallBridgeクラスタのFQDN。このレコードは、すべてのCallBridgeクラスタピアに解決される必要があります。 |
| SAN:cms.uc.local | CallBridgeクラスタのFQDN。このレコードは、すべてのCallBridgeクラスタピアに解決される必要があります。 |
| SAN:cms1.uc.local | CallBridge 1 FQDN。 |
| SAN:cms2.uc.local | CallBridge 2 FQDN。 |
| SAN:cms3.uc.local | CallBridge 3 FQDN。 |
CMS CLIを使用すると、証明書の内容を表示できます。
cms1> pki inspect cmsuccluster.cer
Checking ssh public keys...not found
Checking user configured certificates and keys...found
File contains a PEM encoded certificate
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
60:00:00:00:21:db:36:e8:b9:0d:96:44:41:00:00:00:00:00:21
Signature Algorithm: sha256WithRSAEncryption
Issuer: DC=local, DC=uc, CN=DC-CA
Validity
Not Before: Mar 16 19:00:53 2018 GMT
Not After : Mar 16 19:10:53 2020 GMT
Subject: C=US, ST=NC, L=RTP, O=Systems, OU=Cisco, CN=CMS.UC.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b8:41:69:d9:1d:47:ef:b1:23:70:ae:69:da:e3:
ff:12:f8:97:2b:ee:1e:c0:6c:66:e4:95:3f:8a:74:
4d:ec:fc:1e:0d:38:56:1b:00:5c:ce:6d:d3:68:13:
e4:9d:b6:e7:7d:de:c4:a4:f3:00:02:11:e5:33:06:
b4:f6:64:29:c3:77:62:a9:dc:9d:ad:a2:e9:c1:0b:
72:f4:18:af:df:d3:e3:f4:4a:5d:66:e5:e8:4f:63:
09:15:5f:8e:ec:df:86:fb:35:47:99:db:18:d1:b7:
40:4e:b6:b3:b6:66:28:8e:89:15:8b:cc:0f:e6:5c:
e6:2d:de:83:6c:f8:e3:46:49:97:a6:a9:0e:6d:b1:
65:08:8e:aa:fc:f0:ae:2f:c1:c2:cd:b6:4f:a5:eb:
29:32:9a:48:8c:86:6d:1e:3a:c2:22:70:a3:56:e9:
17:01:ef:3a:ce:bb:9f:04:47:e5:24:e0:16:ba:c0:
85:df:92:4d:51:d2:95:bf:84:f7:9a:2e:c0:31:e9:
9f:91:4f:4a:ce:2c:27:17:f8:ae:3e:96:4e:3b:0a:
15:1a:66:cf:e9:12:96:e1:17:ee:65:3c:04:7a:c0:
a0:b3:09:fd:3e:16:08:c6:0b:36:51:57:cb:d8:09:
a3:40:d0:2c:ae:d6:06:e0:8c:06:de:b7:ce:24:83:
28:69
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:CMS.UC.local, DNS:CMS.UC.local, DNS:CMS1.UC.local, DNS:CMS2.UC.local, DNS:CMS3.UC.local
X509v3 Subject Key Identifier:
FE:EF:64:D6:85:7A:62:C5:CA:7B:64:10:B7:F9:E7:18:1D:65:0B:70
X509v3 Authority Key Identifier:
keyid:B5:FC:2D:1E:7F:D9:3E:68:F4:B2:78:1F:F0:E8:B2:FC:80:7F:9C:E8
X509v3 CRL Distribution Points:
Full Name:
URI:ldap:///CN=DC-CA,CN=DC,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=uc,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint
Authority Information Access:
CA Issuers - URI:ldap:///CN=DC-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=uc,DC=local?cACertificate?base?objectClass=certificationAuthority
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
1.3.6.1.4.1.311.21.7:
0..&+.....7.....\...........A........N...O..d...
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
1.3.6.1.4.1.311.21.10:
0.0
..+.......0
..+.......
Signature Algorithm: sha256WithRSAEncryption
83:31:16:15:74:41:98:e4:40:02:70:cc:6e:c0:53:15:8a:7a:
8a:87:0a:aa:c8:99:ff:5b:23:e4:8b:ce:dd:c0:61:9c:06:b4:
3d:22:91:b6:91:54:3a:99:8d:6e:db:18:27:ef:f7:5e:60:e6:
48:a2:dd:d5:85:1d:85:55:79:e0:64:1a:55:22:9e:39:0c:27:
53:a4:d8:3f:54:fd:bc:f9:d4:6e:e1:dd:91:49:05:3e:65:59:
6e:d4:cd:f6:de:90:cb:3d:b3:15:03:4b:b8:9d:41:f1:78:f5:
d9:42:33:62:b5:18:4f:47:54:c9:fa:58:4b:88:aa:0d:f6:26:
9b:fb:8f:98:b4:82:96:97:24:fe:02:5b:03:04:67:c2:9e:63:
3d:02:ae:ef:92:a7:be:ad:ca:7e:4e:d2:1e:54:e6:bf:75:3b:
72:32:7c:d6:78:3f:5e:b9:e6:43:bd:1c:74:20:46:57:1b:81:
c2:4b:b4:fc:9f:cc:c9:63:a8:2d:fd:dd:09:3f:24:d6:ac:f7:
7c:bd:26:80:a5:b4:d1:a7:c8:fb:3d:d4:a7:93:70:d1:5c:77:
06:9e:1c:f8:6a:81:a5:97:91:e9:21:e9:7a:df:a3:64:ab:ed:
15:c7:be:89:5f:1e:53:a7:b5:01:55:ab:a2:cd:8f:67:8d:14:
83:bc:29:a1
cms1>
[Subject]フィールドと[X509v3 Subject Alternative Name]フィールドに注意してください。これらは、Microsoft環境で信頼関係を構築する際に非常に重要になります。
Subject: C=US, ST=NC, L=RTP, O=Systems, OU=Cisco, CN=CMS.UC.local
X509v3 Subject Alternative Name:
DNS:CMS.UC.local, DNS:CMS.UC.local, DNS:CMS1.UC.local, DNS:CMS2.UC.local, DNS:CMS3.UC.local
DNSレコード要件：単一CallBridge
表2aに、DNSサーバの設定例を示します。各フィールドの意味を説明します。
表2a
| A レコード | IPの例 | 説明 |
| cms.uc.local | 10.10.10.1 | CallBridge |
| fe.skype.local | 10.10.10.5 | Skypeフロントエンド完全修飾ドメイン名(FQDN) |
DNSレコード要件 – クラスタ化CallBridge
表2bに、DNSサーバの設定例を示します。各フィールドの意味を説明します。
表2b
| A レコード | IPの例 | 説明 |
| cms1.uc.local | 10.10.10.1 | CallBridge 1 |
| cms2.uc.local | 10.10.10.2 | CallBridge 2 |
| cms3.uc.local | 10.10.10.3 | CallBridge 3 |
| cms.uc.local | 10.10.10.1 10.10.10.2 10.10.10.3 |
クラスタ内のすべてのCallBridgeに解決されるAレコード。これは、CallBridgeクラスタの完全修飾ドメイン名(FQDN)と呼ばれます |
| fe.skype.local | 10.10.10.5 | Skypeフロントエンド完全修飾ドメイン名(FQDN) |
コンフィギュレーション
SIPメディア暗号化
[Configuration] > [Call Settings]に移動します。SIPメディア暗号化を許可に設定する必要があります。
着信ルール
表3に、[着信コール – コールマッチング(Incoming Calls - Call Matching)]設定のすべてのフィールドの意味を示します。
表 3
| [着信コール照合ダイヤルプラン(Incoming Call Matching Dial Plan)]フィールド | 説明 |
| ドメイン名 | このドメインでコールが受信された場合は、URIのユーザ部分を使用して、有効なターゲットの一致を検索します。 |
| 優先順位 | これにより、ルールが考慮される順序が決まります。最初に、より大きい値がチェックされます。小さい数値が最後にチェックされます。 |
| ターゲットスペース | yesに設定されている場合：uriのユーザ部分がスペースに一致すると、コールはそのスペースに接続します。 |
| ターゲットユーザ | yesに設定されている場合：URIのユーザ部分がCMAユーザと一致する場合、コールはそのユーザへのコールを試行します。 |
| ターゲットIVR | yesに設定されている場合：uriのユーザ部分が設定済みのIVRと一致すると、コールはそのIVRに接続されます。 |
| ターゲットLync | yesに設定されている場合：URIのユーザ部分が、Skype for Business会議のPSTNダイヤルイン番号と一致する場合、その会議にデュアルホームコールとして接続します。 |
| Lync Simplejoinを対象 | yesに設定されている場合：URIのユーザー部分をHTTPSターゲットに変換し、そのURLでホストされているOffice365会議を検索してみてください。 |
| テナント | これにより、このルールを考慮するテナントが決まります。 |
表4に、[着信コール – コール転送(Incoming Calls - Call Forwarding)]設定のすべてのフィールドの意味を示します。
表 4
| [着信転送ダイヤルプラン(Incoming Call Forwarding Dial Plan)]フィールド | 説明 |
| ドメイン照合パターン | このドメインでコールが受信された場合は、設定されているとおりにドメインを転送または拒否します。 |
| 優先順位 | これにより、ルールが考慮される順序が決まります。最初に、より大きい値がチェックされます。小さい数値が最後にチェックされます。 |
| [転送（Forward）] | コールを転送するように設定されている場合は、発信ルールによって処理されます。rejectに設定すると、コールは拒否され、転送されません。 |
| 発信者 ID |
がドメインのfrom部分を通過するように設定されている場合は、前に進みます。ダイヤルプランを使用するように設定されている場合、発信規則で設定されているように、開始部分が書き換えられます。 注：CallBridgeがクラスタ内にある場合、Lync/Skypeドメインに一致するルールにパススルーを使用することはできません。これにより、ゲートウェイコールのプレゼンテーションが中断されます。 |
| リライトドメイン | 有効にした場合、着信側ドメインを[Forwarding Domain]フィールドで設定した値に変更します。 |
| 転送ドメイン | rewrite domainが有効な場合、着信側ドメインはこのフィールドの値に変更されます。 |
着信ルールの設定例：単一のCallBridge
この環境では、物事は非常に簡単です。クラスタ化されたCallBridgeを使用していないため、各ドメインを発信者IDとしてパススルーを使用するように設定できます。これは、プレゼンテーションの共有が中断されるため、クラスタ環境では実行できません。
さらに、「Targets Lync」がtrueに設定されたドメインSkype.localの通話照合ルールがあります。つまり、PSTNダイヤルイン番号でLync/Skype会議にコールすると、デュアルホームコールとして接続できるようになります。
着信規則の設定例：クラスタ化されたCallBridge
この環境では、3つのCallBridgeで構成されるCallBridgeクラスタを使用しています。このため、ドメインをuc.localに書き換えるように設定されたCallBridgeごとに1つのコール転送ルールが必要です。これは、Lync/SkypeユーザがUC環境からユーザにコールバックするときに、実際にcms1.uc.local、cms2.uc.local、またはcms3.uc.localのドメインにコールを発信するためです。残念ながら、これはクラスタ化されたCallBridge環境でコンテンツを動作させるために必要な設定の制限です。コールをuc.local sipプロキシに転送する前に、これをuc.localに戻す必要があります。
さらに、「Targets Lync」がtrueに設定されたドメインSkype.localの通話照合ルールがあります。つまり、PSTNダイヤルイン番号でLync/Skype会議にコールすると、デュアルホームコールとして接続できるようになります。
アウトバウンドルール
表5に、発信コール設定のすべてのフィールドの意味を示します。
表 5
| [発信ダイヤルプラン(Outbound Dial Plan)]フィールド | 説明 |
| Domain | このドメインへの発信には、この発信ルールを使用します |
| 使用するSIPプロキシ | このドメインのコールを送信するSIPプロキシ |
| ローカル連絡先ドメイン | これにより、連絡先ヘッダーに入れる値が決まります。Lync/Skype統合では、この値をCallBridgeのFQDNに設定する必要があります。 注：Lync/SkypeのSIPプロキシを使用する発信ルールでは、このフィールドを設定する必要があります。Lync/Skype以外のSIPプロキシを使用する発信ルールでは、このフィールドを設定しないでください。 |
| ドメインからローカル | これにより、fromヘッダーに入れる値が決まります。これは、SIPプロキシに表示される発信者IDアドレスです。このフィールドを空白のままにすると、設定された「ローカル連絡先ドメイン」が使用されます。Lync/Skypeはこれをコールバックとプレゼンテーション共有の宛先URIとして使用します。 注：この値は、コールがゲートウェイコールで、使用される着信ダイヤルルールの[発信者ID(Caller ID)]が[パススルー(Passthrough)]に設定されている場合は使用されません。 |
| トランク タイプ | これにより、SIPプロキシとの通信に使用されるSIPのバリエーションが決まります。 |
| 動作 | これにより、優先順位の低いルールのチェックを続行するか、コールを完了できなかった一致が発生した場合に検索を停止するかが決まります。 |
| 優先順位 | これにより、ルールが考慮される順序が決まります。最初に、より大きい値がチェックされます。小さい数値が最後にチェックされます。 |
| 暗号化 | これにより、暗号化されたSIPを使用するか、暗号化されていないSIPを使用するかを決定します。 |
| テナント | これにより、このルールを考慮するテナントが決まります。 |
| Call Bridgeスコープ | これにより、この発信ダイヤルルールを考慮するCallBridgeが決定されます。クラスタ化されたCallBridgeでは、各CallBridgeから正しい連絡先ドメインが送信されるようにするために、これが必要です。 注：この値は、次に説明するようにAPIを使用してのみ設定できます。 |
発信コールの設定例：単一のCallBridge
再び 単一のCallBridge環境は、クラスタ環境よりも非常に単純であることがわかります。上記の注意点の1つは、連絡先ドメインが指定されていることです。これは、ローカル連絡先ドメインLync/Skypeがセキュリティ上の理由でコールを拒否するため、CallBridgeの完全修飾ドメイン名(FQDN)を指定しない場合に発生します。着信フォワーディングルールはパススルーを使用するように設定されているため、この例ではfromドメインを実際には書き換えません。
発信コールの設定例：クラスタ化CallBridge
この環境では、3つのCallBridgeで構成されるCallBridgeクラスタを使用しています。このため、各CallBridgeに対して、異なるローカル連絡先ドメイン、ドメインからのローカル、およびスコープを持つ1つのアウトバウンドルールが必要です。すべてのCallBridgeからCisco Unified Communications Managerにコールをルーティングするために必要なアウトバウンドルールは1つだけです。スコープを設定するには、APIを使用する必要があります。
APIを使用したスコープの変更：クラスタ化されたCallBridgeのみ
発信コールルールを作成した後、そのルールのスコープは<all>に設定されます。つまり、アウトバウンドルールは、クラスタ内のすべてのCallBridgeで使用されます。Lync/Skypeをポイントする発信ルールでは、どのCallBridgeに接続しているかによって、異なる連絡先とヘッダーを使用する必要があります。これを行うには、CallBridgeごとに異なる発信ルールを作成する必要があります。CallBridgeでは、contact/fromフィールドがそのCallBridgeと一致します。APIを使用して、これらの発信ダイヤルルールの範囲を設定し、そのルールに一致するCallBridgeでのみ処理できるようにする必要があります。
クラスタ内のすべてのCallBridgeのリストを取得します
ブラウザで、CMS APIの/callbridgesページに移動します。これにより、クラスタ内のすべてのCallBridgeが表示されます。
これで、すべてのCallBridgeのIDを取得しました。IDは環境によって異なります。CallBridge cms1.uc.localを参照する場合、e4ab61ea-b5b4-4fac-ad4a-9979badea4e4のIDを使用する必要があります。
すべての発信ダイヤルルールのリストを取得します
次に、アウトバウンドルールを調べて、IDを取得する必要があります。ブラウザで、APIの/outbounddialplanrulesページに移動します。
<outboundDialPlanRules total="4">
<outboundDialPlanRule id="7c76b6c7-4c42-45b0-af47-796cb6737e4e">
<domain>UC.local</domain>
<priority>0</priority>
</outboundDialPlanRule>
<outboundDialPlanRule id="b8cf4056-7f56-43a5-b67b-861253d5ca32">
<domain>skype.local</domain>
<priority>0</priority>
</outboundDialPlanRule>
<outboundDialPlanRule id="4ae1d777-48b7-423b-a646-a329e1e822af">
<domain>skype.local</domain>
<priority>0</priority>
</outboundDialPlanRule>
<outboundDialPlanRule id="05f00293-50fd-4c17-9452-dec224b43430">
<domain>skype.local</domain>
<priority>0</priority>
</outboundDialPlanRule>
</outboundDialPlanRules>
これで私はすべてのルールのIDを持っていますが、どれが正しいのかわかりません。最初のルールはUC.localに対するものなので気にしません。その範囲を設定する必要はありません。Skype.localに対する残りの発信ルールにどのルールが適しているかを知る必要があります。したがって、一度に1つずつ開始すると、IDとCallBridgeが照合されます。
ブラウザで/outbounddialplanrules/b8cf4056-7f56-43a5-b67b-861253d5ca32に移動します。ここでリストされている連絡先ヘッダーを読み取ると、このルールはCMS1.UC.local用であることがわかります。したがって、このルールの範囲をCMS1.UC.localに設定する必要があります。
PUT the CallBridge Scope in
私のお気に入りのAPIツールを使用して、以下の本文を含む/outbounddialplanrules/b8cf4056-7f56-43a5-b67b-861253d5ca32のapiにPUTをします。
scope: callBridge callBridge: e4ab61ea-b5b4-4fac-ad4a-9979badea4e4
このスクリーンショットでは、PostManを使用してこの要求を送信しています。
このHTTP PUTが成功すると、WebAdminの発信ダイヤルルールページにスコープが適用されたことが反映されます。CallBridgeのWebadminからスコープが適用されたことを確認すると、<local>と表示されます。別のCallBridgeのWebadminを使用して発信ダイヤルルールを表示する場合、スコープフィールドにCallBridge FQDNが表示されます。範囲<all>は、すべてのCallBridgeでルールが使用されることを意味します。スコープ<none>は、スコープが有効になっているが、スコープに一致するCallBridgeがないことを意味します。
1つのCallBridgeのスコープを設定した後、追加のCallBridgeごとにスコープを設定する必要があります。この設定が完了すると、Skypeドメインのすべての発信ルールにスコープが必要になります。
CMSサービスアカウント
WebAdminの[General Configuration]ページには、[Lync Edge settings]セクションがあります。TURNサービスを利用したり、PSTNダイヤルイン番号を使用してデュアルホーム会議に参加したりするには、これを設定する必要があります。
表6に、Lyncエッジ設定の各フィールドの意味を示します。
表 6
| [Lyncエッジ設定]フィールド | 説明 |
| Server address | フロントエンドプールの完全修飾ドメイン名(FQDN) |
| ユーザ名 | CMSに使用するサービスアカウントのユーザ名 |
| 登録数 | 登録する異なるユーザアカウントの数。ここで値が設定されていない場合、上記のユーザ名だけが登録されます。ここで数値を適用すると、URIのユーザ部分に1 ～ Xの数値がサフィックスとして適用されます。ここで、Xは、このフィールドで設定された数値です。 |
CMSサービスアカウントの設定例
CMS1の設定：
この設定では、cms1serviceuser1@skype.local、cms1serviceuser2@skype.local、cms1serviceuser3@skype.local、... cms1serviceuser11@skype.local、およびcms1serviceuser12@skype.localがfe.skype.localに登録されます。この例ではクラスタ環境なので、他のCallBridge用のサービスアカウントを作成し、個別に設定する必要もあります。この例では、ユーザ名が異なることに注意してください。CMS1では、ユーザ名の前にcms1が付きます。CMS2では、ユーザ名の前にcms2が付きます。CMS3では、プレフィックスはcms3です。これらのアカウントはすべてSkype for Business環境で有効になりました。Trusted Application Poolは「Treat as authenticated」で設定されているため、登録するパスワードを指定する必要はありません。
CMS2の設定：
CMS3の設定：
CMSサービスアカウントの確認
CMS WebAdminのステータスページに、Lync/Skypeユーザが正常に登録されたかどうかを示します。次の例では、登録を1つだけ設定し、正常に完了しています。ステータスに長い間進行中の登録が示されている場合は、SIPおよびDNSログを収集して、障害が発生している理由を判別します。
Lync/Skypeの設定
Lync/Skype管理シェルで次のコマンドを適用します。フロントエンドサーバでコマンドを適用します。
単一のCallBridge
まず、CallBridgeを信頼するようにSkypeに指示する必要があります。そのためには、信頼できるアプリケーションプールを追加します。Microsoftの用語では、「プール」は「クラスタ」を意味するだけです。 このシナリオでは、クラスタは1つのCallBridgeのクラスタにすぎません。クラスタのIDは、CallBridgeで使用されている証明書の共通名と一致する必要があります。Microsoftはこれをセキュリティチェックとして使用しています。SANにIDを持たせるだけでは不十分です。共通名が一致しない場合、MicrosoftはTCP接続を切断します。このコマンドを使用する場合、idはCallBridge FQDNである必要があります。レジストラは、これらの接続を処理するフロントエンドプールのFQDNである必要があります。サイトはLync/SkypeサイトIDである必要があります。レジストラまたはサイトに使用する値がわからない場合は、Lync/Skype管理者に問い合わせてください。
New-CsTrustedApplicationPool -Identity CMS.UC.local -Registrar fe.skype.local -site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true
次に、ポート5061でCallBridge（信頼できるアプリケーションプール）からの着信通信を許可するように、Microsoft環境を設定する必要があります。
New-CsTrustedApplication -ApplicationId AcanoApplication -TrustedApplicationPoolFqdn CMS.UC.local -Port 5061
現在、Microsoft環境はコールを受け入れるように設定されていますが、コールバックを行うこともできず、ゲートウェイコールのプレゼンテーションを送信することもできません。これを修正するには、スタティックルートを追加する必要があります。単一のCallBridgeシナリオでは、UC.localドメインへのすべてのコールを許可するために必要なルートは1つだけです。次のコマンドのDestinationは、SIP要求を送信するCallBridgeのFQDNです。MatchURIフィールドは、使用するURIのドメイン部分です。Lync/Skype環境では、MatchURIごとに1つのスタティックルートしか作成できないことに注意してください。
$x1=New-CsStaticRoute -TLSRoute -Destination “CMS.UC.local" -MatchUri “UC.local" -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x1}
最後に、Skypeに対して、これまでの変更をすべて実装するように指示する必要があります。
Enable-CsTopology
クラスタ化CallBridge
まず、CallBridgeクラスタを信頼するようにSkypeに指示する必要があります。そのためには、信頼できるアプリケーションプールを追加します。Microsoftの用語では、「プール」は「クラスタ」を意味するだけです。 クラスタのIDは、CallBridgeで使用されている証明書の共通名と一致する必要があります。 Microsoftはこれをセキュリティチェックとして使用しています。SANにIDを持たせるだけでは不十分です。共通名が一致しない場合、MicrosoftはTCP接続を切断します。このコマンドを使用する場合、idはCallBridge FQDNである必要があります。ComputerFqdnは、クラスタ内の最初のCallBridgeのFQDNである必要があります。ComputerFqdnを指定すると、Lync/Skype環境に、このサーバが1台のサーバだけのクラスタではないことを示します。レジストラは、これらの接続を処理するフロントエンドプールのFQDNである必要があります。サイトはLync/SkypeサイトIDである必要があります。レジストラまたはサイトに使用する値がわからない場合は、Lync/Skype管理者に問い合わせてください。
New-CsTrustedApplicationPool -Identity CMS.UC.local -ComputerFqdn CMS1.UC.local -Registrar fe.skype.local -site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true
この環境では、信頼できるアプリケーションコンピュータとして2つのCallBridgeを追加する必要があります。最初のCallBridgeは、上記の信頼できるアプリケーションプールを作成したときに既に追加されています。これらのコンピュータを追加する場合は、作成したプールに関連付ける必要があります。これは、信頼する必要がある追加のコンピュータがクラスタ内にあることをSkypeに伝えます。ここで使用するすべてのコンピュータIDは、CallBridge証明書にSANとして記載されている必要があります。 これらのIDは、CallBridgeの発信ダイヤルルールの連絡先ヘッダーと一致している必要があります。一致しない場合、MicrosoftはTCP接続を切断します。
New-CsTrustedApplicationComputer -Identity CMS2.UC.local -Pool CMS.UC.local New-CsTrustedApplicationComputer -Identity CMS3.UC.local -Pool CMS.UC.local
次に、ポート5061でCallBridgeクラスタ（信頼できるアプリケーションプール）からの着信通信を許可するように、Microsoft環境を設定する必要があります。
New-CsTrustedApplication -ApplicationId AcanoApplication -TrustedApplicationPoolFqdn CMS.UC.local -Port 5061
現在、Microsoft環境はコールを受け入れるように設定されていますが、コールバックを行うこともできず、ゲートウェイコールのプレゼンテーションを送信することもできません。これを修正するには、スタティックルートを追加する必要があります。まず、UC.localドメインへのすべてのコールを許可するためのスタティックルートを追加する必要があります。次のコマンドのDestinationは、SIP要求を送信するCallBridgeのFQDNです。MatchURIフィールドは、使用するURIのドメイン部分です。Lync/Skype環境では、MatchURIごとに1つのスタティックルートしか作成できないことに注意してください。宛先はCallBridgeクラスタのFQDNであり、クラスタの各メンバーのDNS Aレコードを持っているため、Lync/SkypeはすべてのCallBridgeにトラフィックを送信できます。したがって、1つがダウンした場合、ドメインの要求をクラスタ内の別のCallBridgeに自動的にルーティングできます。
$x1=New-CsStaticRoute -TLSRoute -Destination “CMS.UC.local" -MatchUri “UC.local" -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x1}
次に、クラスタ内の各CallBridgeに対して追加のスタティックルートを作成する必要があります。これは、コールバックとプレゼンテーションが機能するための要件です。
$x2=New-CsStaticRoute -TLSRoute -Destination “CMS1.UC.local" -MatchUri “CMS1.UC.local" -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x2}
$x3=New-CsStaticRoute -TLSRoute -Destination “CMS2.UC.local" -MatchUri “CMS2.UC.local" -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x3}
$x4=New-CsStaticRoute -TLSRoute -Destination “CMS3.UC.local" -MatchUri “CMS3.UC.local" -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x4}
最後に、Skypeに対して、これまでの変更をすべて実装するように指示する必要があります。
Enable-CsTopology
トラブルシューティング
CMSからのログの収集
問題を診断する最初のステップは、問題の場所を特定することです。これを行うには、Cisco Meeting Serverからのログを分析する必要がありますが、最初にログを収集する必要があります。収集するログに関する個人的な推奨事項を次に示します。
最初に、WebAdminインターフェイス経由ですべてのCallBridgeのSIPおよびDNSデバッグを有効にします。これを行うには、WebAdminに移動し、[Logs] > [Detailed Tracing]に移動します。ここから次の30分間、SIPおよびDNSロギングを有効にします。この時間は、問題を検出して診断するのに十分な時間です。ログの有効化はクラスタ間で共有されないため、すべてのCallBridgeに対して個別に行う必要があることに注意してください。
次に、すべてのCallBridgeでパケットキャプチャを有効にします。この接続を行うには、SSH経由で各CallBridgeに接続し、コマンドpcap <interface>（ここで<interface>はインターフェイストラフィックを使用する必要があります）を実行します。ほとんどの場合、これはインターフェイスaになります。そのため、コマンド「pcap a」は、接続しているCallBridgeのインターフェイスaでパケットキャプチャを開始します。
すべてのインターフェイスでパケットキャプチャが実行されたら、次の手順は問題を発生させることです。先に進んでコールを試すか、失敗したコールを何でもしてください。これが完了すると、すべてのパケットキャプチャが終了します。これは、すべてのSSHウィンドウでCtrl+Cを入力することで実行できます。パケットキャプチャが完了すると、生成されたファイルの名前が画面に書き込まれます。次の手順でダウンロードする必要があるため、このファイル名を追跡します。
最後に、CallBridgeからログを収集する必要があります。これを行うには、SFTP経由で各CallBridgeに接続します。ファイルlogbundle.tar.gzと生成されたパケットキャプチャファイルをダウンロードします。このファイルはCMS2.2+でのみ使用できます。CMSバージョン2.3+では、CMSの完全な設定が含まれます。バージョン2.2を実行している場合は、着信/発信ルールが含まれないため、これらのページのスクリーンショットやLyncエッジの設定を参考にすることをお勧めします。収集したログ/スクリーンショットは、ログの取得元であるCallBridgeに一致する名前を持つ別のフォルダに保存してください。これは、ログが混乱しないようにするのに役立ちます。
Lync/Skype構成の表示
これらのコマンドは、Lync/Skype設定のトラブルシューティングに非常に役立ちます。このドキュメントでは、設定を作成および表示するためのコマンドが提供されていますが、設定を削除するためのコマンドは提供されていません。これは、Lync/Skype環境を完全に理解している管理者が実行しない限り、構成を削除することは危険であるためです。構成を削除する必要がある場合は、Lync/Skype管理者と協力して削除してください。
| コマンド | 説明 |
| Get-CsTrustedApplicationPool | このコマンドは、Lync/Skypeによって信頼されているクラスター（プール）を一覧表示します。このプールのIDは、CallBridge証明書の共通名と一致する必要があります。 単一のCallBridge環境でも、1つのCallBridgeクラスタ（プール）をここに指定する必要があります。 |
| Get-CsTrustedApplicationComputer | このコマンドは、Lync/Skypeによって信頼されているサーバーと、これらのサーバーが関連付けられているプールを一覧表示します。ここにあるすべてのコンピュータは、CallBridgeによって送信された証明書で識別される必要があります。単一のCallBridge環境では、これは通常、共通名です。クラスタ環境では、これらのコンピュータをサブジェクト代替名(SAN)エントリとしてリストする必要があります。さらに、ここにあるすべてのコンピュータは、CallBridge発信ダイヤルルールのローカル連絡先ドメインエントリによって識別される必要があります。 |
| Get-CsTrustedApplication | このコマンドは、どのサービスの信頼できるアプリケーションプールとの通信を許可するかをリストします。Lync/SkypeとのCMS通信では、TLS暗号化SIPにTCPポート5061を使用します。 |
| Get-CsStaticRoutingConfiguration | Select-Object -ExpandPropertyルート |
このコマンドは、Lync/Skypeが要求の転送に使用するスタティックルートをリストします。[MatchURI]フィールドは、SIPメッセージの宛先ドメインです。XMLの[TLS Fqdn]フィールドには、このトラフィックの宛先サーバが表示されます。 |
Lync/Skype Getコマンドの出力例
次に、このドキュメントで説明されている3つのCallBridgeクラスタシナリオで発行された上記のLync/Skype Getコマンドの出力を示します
PS C:\Users\administrator.SKYPE> Get-CsTrustedApplicationPool
Identity : TrustedApplicationPool:CMS.UC.local
Registrar : Registrar:lyncpoolfe01.skype.local
FileStore :
ThrottleAsServer : True
TreatAsAuthenticated : True
OutboundOnly : False
RequiresReplication : False
AudioPortStart :
AudioPortCount : 0
AppSharingPortStart :
AppSharingPortCount : 0
VideoPortStart :
VideoPortCount : 0
Applications : {urn:application:acanoapplication}
DependentServiceList : {}
ServiceId : 1-ExternalServer-1
SiteId : Site:RTP
PoolFqdn : CMS.UC.local
Version : 7
Role : TrustedApplicationPool
PS C:\Users\administrator.SKYPE> Get-CsTrustedApplicationComputer
Identity : CMS1.UC.local
Pool : CMS.UC.local
Fqdn : CMS1.UC.local
Identity : CMS2.UC.local
Pool : CMS.UC.local
Fqdn : CMS2.UC.local
Identity : CMS3.UC.local
Pool : CMS.UC.local
Fqdn : CMS3.UC.local
PS C:\Users\administrator.SKYPE> Get-CsTrustedApplication
Identity : CMS.UC.local/urn:application:acanoapplication
ComputerGruus : {CMS1.UC.local sip:CMS1.UC.local@skype.local;gruu;opaque=srvr:acanoapplication:GMqDXW_1rVCEMQi4qS6ZxwAA, CMS2.UC.local
sip:CMS2.UC.local@skype.local;gruu;opaque=srvr:acanoapplication:_Z9CnV49LFufGDXjnFFi4gAA, CMS3.UC.local sip:CMS3.UC.local@skype.local;gruu;opaque=srvr:acanoapplication:dt8XJKciSlGhEeT62tyNogAA}
ServiceGruu : sip:CMS.UC.local@skype.local;gruu;opaque=srvr:acanoapplication:dQFM4E4YgV6J0rjuNgqxIgAA
Protocol : Mtls
ApplicationId : urn:application:acanoapplication
TrustedApplicationPoolFqdn : CMS.UC.local
Port : 5061
LegacyApplicationName : acanoapplication
PS C:\Users\administrator.SKYPE> Get-CsStaticRoutingConfiguration | Select-Object -ExpandProperty Route
Transport : TransportChoice=Certificate=Microsoft.Rtc.Management.WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=CMS.UC.local;Port=5061
MatchUri : UC.local
MatchOnlyPhoneUri : False
Enabled : True
ReplaceHostInRequestUri : False
Element : <Route xmlns="urn:schema:Microsoft.Rtc.Management.Settings.SipProxy.2008" MatchUri="UC.local" MatchOnlyPhoneUri="false" Enabled="true" ReplaceHostInRequestUri="false">
<Transport Port="5061">
<TLS Fqdn="CMS.UC.local">
<UseDefaultCert />
</TLS>
</Transport>
</Route>
Transport : TransportChoice=Certificate=Microsoft.Rtc.Management.WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=CMS1.UC.local;Port=5061
MatchUri : CMS1.UC.local
MatchOnlyPhoneUri : False
Enabled : True
ReplaceHostInRequestUri : False
Element : <Route xmlns="urn:schema:Microsoft.Rtc.Management.Settings.SipProxy.2008" MatchUri="CMS1.UC.local" MatchOnlyPhoneUri="false" Enabled="true" ReplaceHostInRequestUri="false">
<Transport Port="5061">
<TLS Fqdn="CMS1.UC.local">
<UseDefaultCert />
</TLS>
</Transport>
</Route>
Transport : TransportChoice=Certificate=Microsoft.Rtc.Management.WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=CMS2.UC.local;Port=5061
MatchUri : CMS2.UC.local
MatchOnlyPhoneUri : False
Enabled : True
ReplaceHostInRequestUri : False
Element : <Route xmlns="urn:schema:Microsoft.Rtc.Management.Settings.SipProxy.2008" MatchUri="CMS2.UC.local" MatchOnlyPhoneUri="false" Enabled="true" ReplaceHostInRequestUri="false">
<Transport Port="5061">
<TLS Fqdn="CMS2.UC.local">
<UseDefaultCert />
</TLS>
</Transport>
</Route>
Transport : TransportChoice=Certificate=Microsoft.Rtc.Management.WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=CMS3.UC.local;Port=5061
MatchUri : CMS3.UC.local
MatchOnlyPhoneUri : False
Enabled : True
ReplaceHostInRequestUri : False
Element : <Route xmlns="urn:schema:Microsoft.Rtc.Management.Settings.SipProxy.2008" MatchUri="CMS3.UC.local" MatchOnlyPhoneUri="false" Enabled="true" ReplaceHostInRequestUri="false">
<Transport Port="5061">
<TLS Fqdn="CMS3.UC.local">
<UseDefaultCert />
</TLS>
</Transport>
</Route>
PS C:\Users\administrator.SKYPE>
TACへの連絡
この実装でエラーが発生した場合は、Cisco TACに連絡してください。サービスリクエストをオープンする際には、このドキュメントへのリンクを含めてください。これは、TACエンジニアが設定を理解するのに役立ちます。さらに、前述のようにCisco Meeting Server(CMS)のログをケースに添付し、Lync/SkypeフロントエンドからのすべてのGetコマンドの出力をケースノートに入力すると、非常に便利です。この情報を含めない場合は、TACエンジニアが最初に要求する情報の1つであることが確実です。ケースをオープンする前に、この情報を収集してください。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
12-Oct-2017 |
初版 |
フィードバック