Collaboration Edgeの最も一般的な問題の解決

はじめに

このドキュメントでは、導入段階で最も一般的に発生するCollaboration Edgeの問題をトラブルシューティングする方法について説明します。

背景説明

モバイルおよびリモートアクセス(MRA)は、バーチャルプライベートネットワーク(VPN)を使用しないJabber機能の導入ソリューションです。このソリューションでは、エンドユーザが世界のどこからでも内部エンタープライズ リソースに接続できます。このガイドは、Collaboration Edgeソリューションのトラブルシューティングを行うエンジニアが、導入段階で最も一般的に直面する問題を迅速に特定して解決できるように作成されています。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Unified Communications Manager（CUCM）
• Cisco Expressway Core
• Cisco Expressway Edge
• Cisco IM and Presence(IM&P)
• Cisco Jabber for Windows
• Cisco Jabber for Mac
• Cisco Jabber for Android
• Cisco Jabber for iOS®
• セキュリティ証明書
• ドメイン ネーム システム（DNS）

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• ExpresswayバージョンX8.1.1以降
• CUCMリリース9.1(2)SU1以降およびIM&Pバージョン9.1(1)以降
• Cisco Jabberバージョン9.7以降

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

ログインの問題

JabberがMRA経由でサインインできない

この症状は、さまざまな問題が原因で発生する可能性があります。その一部を次に概説します。

1. 作成されないCollaboration Edgeサービスレコード(SRV)またはポート8443が到達不能

JabberクライアントがMRAを使用して正常にログインできるようにするには、特定のコラボレーションエッジSRVレコードを作成し、外部からアクセスできるようにする必要があります。Jabberクライアントが最初に起動されると、DNS SRVクエリが作成されます。

1. _cisco-uds：このSRVレコードは、CUCMサーバが使用可能かどうかを判断するために使用されます。
   
   
2. _cuplogin：このSRVレコードは、IM&Pサーバが使用可能かどうかを判断するために使用されます。
   
   
3. _collab-edge：このSRVレコードは、MRAが使用可能かどうかを判別するために使用されます。
   
   

Jabberクライアントが起動し、_cisco-udsおよび_cuploginに対するSRV応答を受信しない場合で、_collab-edgeに対する応答を受信する場合は、この応答を使用してSRV応答に示されているExpressway-Eへの接続を試みます。

_collab-edge SRVレコードは、ポート8443を持つExpressway-Eの完全修飾ドメイン名(FQDN)を指しています。_collab-edge SRVが作成されていないか、外部で使用できない場合、または使用可能であってもポート8443に到達できない場合、Jabberクライアントはログインに失敗します。

_collab-edge SRVレコードが解決可能であり、TCPポート8443にCollaboration Solutions Analyzer(CSA)のSRVチェッカーを使用して到達できるかどうかを確認します。

ポート8443に到達できない場合は、セキュリティデバイス（ファイアウォール）がポートをブロックしているか、デフォルトゲートウェイ(GW)またはExp-Eのスタティックルートの設定ミスが原因である可能性があります。

2. VCS Expresswayで受け入れられないか、使用可能な証明書がない

Jabberクライアントは、_collab-edgeに対する応答を受信すると、ポート8443経由でTransport Layer Security(TLS)を使用してExpresswayに接続し、Expresswayから証明書の取得を試行し、JabberクライアントとExpressway間の通信用にTLSを設定します。

ExpresswayにExpresswayのFQDNまたはドメインを含む有効な署名付き証明書がない場合、この操作は失敗し、Jabberクライアントはログインできません。

この問題が発生する場合は、Expresswayの証明書署名要求(CSR)ツールを使用します。このツールは、サブジェクト代替名(SAN)としてExpresswayのFQDNを自動的に含めます。

注:MRAでは、Expressway-CとExpressway-E間、およびExpressway-Eと外部エンドポイント間のセキュアな通信が必要です。

機能ごとのExpressway証明書の要件に関する次の表については、『MRA導入ガイド』を参照してください。

3. エッジ設定にUDSサーバが見つかりません

JabberクライアントがExpressway-Eとのセキュアな接続を正常に確立すると、エッジ設定(get_edge_config)を要求します。このエッジ設定には、_cuploginと_cisco-udsのSRVレコードが含まれています。エッジ設定で_cisco-uds SRVレコードが返されない場合、Jabberクライアントはログインを続行できません。

これを修正するには、_cisco-uds SRVレコードが内部で作成され、Expressway-Cで解決できることを確認します。

DNS SRVレコードの詳細については、『X8.11用MRA導入ガイド』を参照してください。

これは、デュアルドメインの場合によくある症状です。デュアルドメインで実行し、Jabberクライアントがユーザデータサービス(UDS)から返されない場合は、内部DNSで外部ドメインを使用して_cisco-uds SRVレコードが作成されていることを確認する必要があります。

注：ExpresswayバージョンX12.5以降では、_cisco-UDS SRVレコードを内部DNSに追加する必要はありません。この拡張機能の詳細については、『Mobile and Remote Access Through Cisco Expressway Deployment Guide(X12.5)』を参照してください。

4. Expressway-Cのログに次のエラーが記録される：XCP_JABBERD Detail=Unable to connect to host '%IP%', port 7400:(111) Connection Refused

Expressway-Eネットワークインターフェイスコントローラ(NIC)の設定が誤っていると、Extensible Communications Platform(XCP)サーバが更新されない可能性があります。Expressway-Eがこれらの基準を満たしている場合は、次の問題が発生する可能性があります。

1. 単一のNICを使用
2. Advanced Networking Option Keyがインストールされている。
3. Use Dual Network InterfacesオプションがYesに設定されている。

この問題を修正するには、Use Dual Network InterfacesオプションをNoに変更します。

これが問題である理由は、Expressway-Eが誤ったネットワークインターフェイスでXCPセッションをリッスンするため、接続が失敗またはタイムアウトするためです。Expressway-Eは、TCPポート7400でXCPセッションをリッスンします。これは、ルートとしてVCSからnetstatコマンドを使用すると確認できます。

5. Expressway-Eサーバのホスト名/ドメイン名が_collab-edge SRVで設定されている名前と一致しない

DNSページ設定内のExpressway-Eサーバのホスト名/ドメインが、_collab-edge SRV応答で受信したホスト名/ドメインと一致しない場合、JabberクライアントはExpressway-Eと通信できません。Jabberクライアントは、get_edge_config応答のxmppEdgeServer/Address要素を使用して、Expressway-EへのXMPP接続を確立します。

次に、Expressway-EからJabberクライアントへのget_edge_config応答のxmppEdgeServer/Addressの例を示します。

<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example URL</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>

これを回避するには、_collab-edge SRVレコードがExpressway-Eのホスト名/ドメイン名と一致していることを確認します。この問題はCisco Bug ID CSCuo83458に記載されており、Cisco Bug ID CSCuo82526で部分的なサポートが追加されています。

6. WebEx Connectサブスクリプションが使用中のためログインできない

Jabber for Windowsのログには次のように表示されます。

2014-11-22 19:55:39,122 INFO  [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is  'Code: IS_WEBEX_CUSTOMER; Server: 
http://URL server; 
Url: http://example URL server';;;.2014-11-22 
19:55:39,122 INFO  [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] - 
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122 
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://example URL server2014-11-22 
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://example URL server/cas/FederatedSSO?org=example URL]2014-11-22 
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url] 
skipLocal : [0]  value: [http://website URL/cas/FederatedSSO?org=example URL]
success: [true] configStoreName: [LocalFileConfigStore]

ログイン試行はWebEx Connectにリダイレクトされます。

永続的に解決するには、WebExに連絡して、サイトを使用停止にする必要があります。

回避策

短期的には、これらのオプションのいずれかを使用してルックアップから除外できます。

• このパラメータをjabber-config.xmlに追加します。次に、jabber-config.xmlファイルをCUCMのTFTPサーバにアップロードします。クライアントが最初に内部でログインする必要があります。
  
  

  <?xml version="1.0" encoding="utf-8"?>
  <config version="1.0">
  <Policies>
  <ServiceDiscoveryExcludedServices>WEBEX<
  /ServiceDiscoveryExcludedServices>
  </Policies>
  </config>

• アプリケーションの観点から、次を実行します。
  msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX

注:2つ目のオプションは、モバイルデバイスでは機能しません。

• WEBEXサービスを除外するクリック可能なURLを作成します。
  ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX

UCサービスディスカバリの詳細、および『Cisco Jabber 12.8のオンプレミス導入』で一部のサービスを除外する方法について説明します。

7. Expressway-Cサーバでエラーメッセージ「Configured but with errors」が表示されます。Provisioning server：トラバーサルサーバ情報を待機しています。

Status > Unified Communicationsの順に移動すると、「Configured but with errors.Provisioning server: Waiting for traversal server info.」というエラーメッセージが表示されます。Unified CMの登録とIM&Pサービスについて、Expressway-Cに設定された内部DNSサーバに、Expressway-Eの2つのDNS Aレコードが含まれています。Expressway-Eに複数のDNS Aレコードが存在する理由としては、該当するユーザがExpressway-EでスタティックNATが有効にされた単一NICからスタティックNATが有効にされたデュアルNICに移動した場合や、その逆に移動した場合に、内部DNSサーバで適切なDNS Aレコードを削除し忘れた場合が考があります。したがって、Expressway-CでDNSルックアップユーティリティを使用してExpressway-EのFQDNを解決すると、2つのDNS Aレコードが見つかります。

解決方法

Expressway-E NICがスタティックNATを使用する単一のNIC用に設定されている場合：

1. Expressway-Cで設定されたDNSサーバで、Expressway-Eの内部IPアドレスに対応するDNS Aレコードを削除します。
2. CMD経由でExpressway-CのDNSキャッシュとユーザPCをフラッシュします(ipconfig /flushdns)。
3. Expressway-Cサーバをリブートします。

Expressway-E NICが、スタティックNATが有効なデュアルNIC用に設定されている場合：

1. Expressway-Cで設定されたDNSサーバから、Expressway-Eの外部 IPアドレスに対応するDNS Aレコードを削除します。
2. CMD経由でExpressway-CとユーザPCのDNSキャッシュをフラッシュします(ipconfig /flushdns)。
3. Expressway-Cサーバをリブートします。

8. Microsoft DirectAccessがインストールされています

Jabberクライアントと同じPCでMicrosoft DirectAccessを使用している場合、リモートでログインしようとすると、MRAが機能しなくなる可能性があります。DirectAccessは、PCがVPNを使用した場合と同様に、強制的にDNSクエリを内部ネットワークにトンネリングします。

注:Microsoft DirectAccessは、Jabber over MRAではサポートされていません。トラブルシューティングはすべてベストエフォートです。DirectAccessの構成は、ネットワーク管理者が行います。

場合によっては、Microsoft DirectAccess名前解決ポリシーテーブル内のすべてのDNSレコードを正常にブロックできます。次のレコードはDirectAccessで処理されません（Jabberは、MRAを使用してパブリックDNS経由でこれらを解決できる必要があります）。

• _cisco-udsのSRVレコード
• cuploginのSRVレコード(_C)
• _collab-edgeのSRVレコード
• すべてのExpressway Eのレコード

9. Expressway逆DNSルックアップが失敗する

バージョンX8.8以降、Expressway/VCSでは、ExpE、ExpC、およびすべてのCUCMノードに対してフォワードおよびリバースDNSエントリを作成する必要があります。 

すべての要件については、『x8.8リリースノート』の「前提条件とソフトウェアの依存関係」および『モバイルおよびリモートアクセス用のDNSレコード』を参照してください。

内部DNSレコードが存在しない場合、reverseDNSLookupを参照するExpresswayログにエラーがある可能性があります。

2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"

Expressway-Cは、Expressway-E IPのPTRレコードのクエリ時に1つのFQDNのみを受信します。DNSから誤ったFQDNを受信した場合は、ログに次の行が表示され、失敗します。

2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname"

登録の問題

ソフトフォンが登録できない、SIP/2.0 405方式が許可されない

Expressway-Cからの診断ログには、Jabberクライアントから送信された登録要求への応答としてSIP/2.0 405 Method Not Allowedメッセージが示されます。これは、Expressway-CとCUCM間のポート5060/5061を使用した現在のセッション開始プロトコル(SIP)トランクが原因である可能性があります。

SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS 
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0 

この問題を修正するには、CUCMで設定されている現在のSIPトランクに適用されているSIPトランクセキュリティプロファイルのSIPポートと、CUCMのExpressway-Cネイバーゾーンを、5065などの別のポートに変更します。これについては、このビデオで詳しく説明します。設定の要約を次に示します。

CUCM

1. リスニングポートが5060(5065)以外の新しいSIPトランクセキュリティプロファイルを作成します。
2. SIPトランクセキュリティプロファイルに関連付けられたSIPトランクを作成し、Expressway-CのIPアドレス、ポート5060に宛先セットを設定します。

Expressway-C

1. CUCM設定に一致する5060(5065)以外のターゲットポートを使用して、CUCMへのネイバーゾーンを作成します。
2. Expressway-CのSettings > Protocols > SIPで、Expressway-Cが引き続き5060でSIPをリッスンしていることを確認します。

ソフトフォンが登録できない、理由=「不明なドメイン」

Expressway-Cからの診断ログに、Event="Registration Rejected" Reason="Unknown domain" Service="SIP" Src-ip="XXX.XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip:XXX.XXX.XXX.XXX"が記録されます。

この問題を修正するには、次の点を確認します。

• Jabberクライアントは、非セキュアなデバイスセキュリティプロファイルを使用しないときに、CUCMでセキュアなデバイスセキュリティプロファイルを使用しますか。
  
  
• Jabberクライアントがセキュアなデバイスセキュリティプロファイルを使用する場合、セキュリティプロファイルの名前はFQDN形式で、そのFQDN名はExpressway-C証明書でSANとして設定されていますか。
  
  
• Jabberクライアントがセキュアなデバイスセキュリティプロファイルを使用する場合、System > Enterprise Parameters > Security Parameters > Cluster Security Modeの順に移動し、CUCMクラスタがセキュアであることを確認するためにCluster Security Modeが1に設定されていることを確認します。値が0の場合、管理者は文書化された手順に従ってクラスタを保護する必要があります。

ソフトフォンが登録できない、理由「アイドルカウントダウンが切れた」

JabberクライアントがREGISTERメッセージで送信する時間枠の間にExpressway-Eログを確認する場合、ここに示すコードスニペットに示されているように、「Idle countdown expired」エラーを探します。

2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144" 
Module="network.tcp" Level="DEBUG":  Src-ip="JabberPubIP" Src-port="4211" 
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144" 
Module="network.tcp" Level="DEBUG":  Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00 
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606" 
Module="network.tcp" Level="DEBUG":  Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle 
countdown expired"

このスニペットは、ファイアウォールのポート5061が開いていることを示します。ただし、十分な時間内に渡されるアプリケーション層トラフィックがないため、TCP接続が閉じられます。

この状況が発生した場合、Expressway-Eの前にあるファイアウォールでSIPインスペクション/アプリケーションレイヤゲートウェイ(ALG)機能がオンになっている可能性が高くなります。この問題を修正するには、この機能を無効にする必要があります。この方法がわからない場合は、ファイアウォールのベンダーの製品マニュアルを参照してください。

SIPインスペクション/ALGの詳細については、『Cisco Expressway-EおよびExpressway-C基本設定導入ガイド』の付録4を参照してください。

ファームウェアで設定された電話プロキシが原因でMRAが失敗する

Expressway-Eからの診断ログには、ポート5061でのTLSネゴシエーションの失敗が示されていますが、ポート8443でのSSLハンドシェイクは成功しています。

2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG":  Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP"  Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"

Jabberからのログ：

-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'URL address' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=URL server name:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.

Jabberからのパケットキャプチャは、Expressway EのIPとのSSLネゴシエーションを示していますが、送信された証明書はこのサーバからのものではありません。

FWには電話プロキシが設定されています。

ソリューション：

FWが電話プロキシを実行していることを確認します。これを確認するには、show run policy-mapコマンドを入力すると、次に似た出力が表示されます。

class sec_sip
inspect sip phone-proxy ASA-phone-proxy

電話サービスを正常に接続するには、電話プロキシを無効にします。

通話関連の問題

MRA経由でコールする場合はメディアなし

シングルおよびデュアルNICの展開でこの問題を引き起こす可能性がある、欠如的で誤った設定の一部を次に示します。

• Expressway-EのSystem > Network Interfaces > IPでスタティックNATが設定されていない。ネットワーク層のNATは引き続きファイアウォールで実行する必要がありますが、この設定はアプリケーション層のIPを変換します。
• TCP/UDPポートがファイアウォールで開かれていません。ポートのリストについては、『Cisco Expressway IPポート使用設定ガイド』を参照してください。

スタティックNATを使用した単一NICの導入は推奨されません。メディアの問題を防ぐための考慮事項を次に示します。

• UCトラバーサルゾーンでは、Expressway-CはExpressway-Eで設定されたパブリックIPアドレスをポイントする必要があります。
• メディアは、外部ファイアウォールに「ヘアピニング」またはリフレクトする必要があります。Cisco ASAファイアウォールを使用した設定例は、「VCS Expressway TelePresenceデバイス用のASAでのNATリフレクションの設定」で確認できます。 

詳細については、『Cisco Expressway-EおよびExpressway-C基本設定導入ガイド』の付録4を参照してください。

MRA経由でPSTNにコールする際にリングバックが発生しない

この問題は、バージョンX8.5より前のExpresswayの制限が原因です。Cisco Bug ID CSCua72781では、Expressway-Cが183 Session Progressまたは180 Ringingの早期メディアをトラバーサルゾーン経由で転送しない方法について説明します。バージョンX8.1.xまたはX8.2.xが稼働している場合は、バージョンX8.5にアップグレードするか、次に示す回避策を実行できます。

183を180に変換するSIPプロファイルを作成して着信ダイヤルピアに適用する場合、Cisco Unified Border Element(CUBE)で回避策を使用できます。例：

voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" 
"SIP/2.0 180 Ringing"

その後、CUCM > CUBEのSIPプロファイルまたはsip-ua設定モード内のCUBE自体のいずれかで180 Early Mediaを無効にします。

disable-early-media 180

CUCMとIM&Pの問題

CUCMの追加を妨げるASCIIエラー 

CUCMをExpressway-Cに追加するときに、CUCMを追加できないASCIIエラーが発生します。

Expressway-CがデータベースにCUCMを追加すると、get関数とlist関数に関連する一連のAXLクエリが実行されます。たとえば、getCallManager、listCallManager、listProcessNode、listProcessNodeService、およびgetCCMVersionなどです。getCallManagerプロセスの実行後、すべてのCUCM Call Manager-trustまたはtomcat-trustを取得するように設定されたExecuteSQLQueryによってプロセスが成功します。

CUCMがクエリを受信して実行すると、CUCMはすべての証明書を報告します。証明書のいずれかに非ASCII文字が含まれている場合、ExpresswayはWebインターフェイスで「ascii codec cannot decode byte 0xc3 in position 42487: ordinal not in range(128)」のようなエラーを生成します。

この問題は、Cisco Bug ID CSCuo54489で追跡され、バージョンX8.2で解決されています。

セキュアな導入でのExpressway-CからCUCMへの5061での発信TLSの失敗

この問題は、CUCMで自己署名証明書を使用し、Tomcat.pem/CallManager.pemが同じサブジェクトを持つ場合に発生します。この問題は、Cisco Bug ID CSCun30200で対処されています。この問題を修正する回避策は、Expressway-CのCUCM設定からtomcat.pemを削除し、TLS検証を無効にすることです。

IM&Pサーバが追加されず、エラーが発生する

IM&Pサーバを追加すると、Expressway-Cによって「This server is not an IM and Presence Server」または「Unable to communicate with .AXL query HTTP error "HTTPError:500''」が報告され、IM&Pサーバが追加されません。

IM&Pサーバの追加の一部として、Expressway-CはAXLクエリを使用して、明示的なディレクトリでIM&P証明書を検索します。Cisco Bug ID CSCul05131が原因で、証明書がそのストアにないため、誤ったエラーが発生します。

その他

Jabberクライアントのボイスメールステータスに「Not connected」と表示される

Jabberクライアントボイスメールのステータスが正常に接続されるようにするには、Expressway-CのHTTP許可リスト内でCisco Unity Connection IPアドレスまたはホスト名を設定する必要があります。

Expressway-Cからこれを実行するには、関連する手順を実行します。

バージョンX8.1およびX8.2の手順

1. Configuration > Unified Communications > Configuration > Configure HTTP server allow listの順にクリックします。
2. New > Enter IP/Hostname > Create entryの順にクリックします。
3. Jabberクライアントからログアウトし、再度ログインします。

バージョンX8.5の手順

1. Configuration > Unified Communications > Unity Connection Serversの順にクリックします。
2. New > Enter IP/Hostname, User account credentials > Add Addressの順にクリックします。
3. Jabberクライアントからログアウトし、再度ログインします。

連絡先の写真がExpressway経由でJabberクライアントに表示されない

モバイルおよびリモートアクセスソリューションでは、連絡先の写真の解決にUDSのみを使用します。これには、写真を保存できるWebサーバが必要です。設定自体は2つの側面から成ります。

1. Contact Photo解決のためにクライアントをWebサーバに転送するように、jabber-config.xmlファイルを変更する必要があります。次の設定はこれを実現します。
   
   

   <Directory>
   <DirectoryServerType>UDS</DirectoryServerType>
   <PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
   /PhotoUriWithToken>
   <UdsServer>%IP%</UdsServer>
   <MinimumCharacterQuery>3</MinimumCharacterQuery>
   </Directory>

2. 1. Configuration > Unified Communications > Configuration > Configure HTTP server allow listの順にクリックします。
   2. New > Enter IP/Hostname > Create entryの順にクリックします。
   3. Jabberクライアントからログアウトし、再度ログインします。Expressway-CのWebサーバが、HTTPサーバ許可リストにリストされている必要があります。

   注：UDSの連絡先写真の解像度の詳細については、Jabberの連絡先写真のドキュメントを参照してください。

Jabberクライアントは、ログイン時にExpressway-E証明書を受け入れるように求められます

このエラーメッセージは、クライアントデバイスによって信頼されているパブリックCAによって署名されていないExpressway Edge証明書、またはドメインがサーバ証明書内にSANとして存在しない証明書に関連している可能性があります。

Expressway証明書受け入れプロンプトからJabberクライアントを停止するには、次の2つの基準を満たす必要があります。

• Jabberクライアントを実行するデバイス/マシンでは、証明書信頼ストアにExpressway-E証明書の署名者がリストされている必要があります。
  
  

  注：モバイルデバイスには大きな証明書信頼ストアが含まれるため、パブリック認証局(CA)を使用すると、この手順は簡単に実行できます。

• collab-edgeレコードに使用するUnified CM登録ドメインは、Expressway-E証明書のSAN内に存在する必要があります。ExpresswayサーバのCSRツールでは、Unified CM登録ドメインをSANとして追加するオプションが提供されます。これは、ドメインがMRA用に設定されている場合にプリロードされます。証明書に署名するCAがドメインをSANとして受け入れない場合は、「CollabEdgeDNS」オプションを使用して、プレフィクス「collab-edge」をドメインに追加することもできます。

関連情報

• Expressway経由のモバイルおよびリモートアクセスガイド
• Cisco Expressway証明書の作成および使用導入ガイド
• ファイアウォールトラバーサル用のCisco TelePresence Video Communication Server(Cisco VCS)IPポートの使用
• Cisco Jabberの導入およびインストールガイド
• テクニカル サポートとドキュメント - Cisco Systems