シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Bidirectional-streams Over Synchronous HTTP(BOSH)を使用するFinesse接続の背後にあるアーキテクチャと、BOSH接続の問題を診断する方法について説明します。
次の項目に関する知識が推奨されます。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
Extensible Messaging and Presence Protocol(XMPP)(Jabberとも呼ばれる)は、クライアントサーバモデルのステートフルプロトコルです。XMPPを使用すると、あるエンティティから別のエンティティに構造化されたeXtensible Markup Language(XML)データを迅速に配信できます。XMPP/Jabberは、インスタントメッセージング(IM)およびプレゼンスアプリケーションで広く使用されています。
すべてのXMPPエンティティは、Jabber ID(JID)で識別されます。
JIDアドレッシング方式:user@domain/resource
ユーザ | XMPPサーバのクライアントユーザ名または会議室の名前 |
domain | XMPPサーバの完全修飾ドメイン名(FQDN) |
リソース | ユーザの特定のエンティティ/エンドポイント(ラップトップ、スマートフォンなど)、セッションID、またはパブリックサブノード名の識別子 |
注:3つのJIDコンポーネントすべてが、すべてのケースで使用されるわけではありません。サーバは通常、ドメイン、user@domainで定義された会議室、およびuser@domain/resourceで定義されたクライアントによって定義されます。
XMPPメッセージはスタンザと呼ばれます。XMPPには、次の3つのコアスタンザがあります。
1.<message>:一方向、受信者1
2.<presence>:1つの方向で多数に公開
3.<iq>:情報/クエリ – 要求/応答
すべてのスタンザはアドレスとアドレスの間であり、ほとんどのスタンザもtype、id、およびxml:languattributesを持ちます。
スタンザ属性 | 目的 |
から | 宛先JID |
から | ソースJID |
種類 | メッセージの目的 |
id | <iq>スタンザの応答と要求をリンクするために使用される一意の識別子 |
xml:lang | スタンザで読み取り可能なXMLのデフォルト言語を定義する |
<message to='person1@example' from='person2@example' type='chat'>
<subject> Team meeting </subject>
<body>Hey, when is our meeting today? </body>
<thread>A4567423</thread>
</message>
WebアプリケーションがXMPPと連携する必要がある場合は、複数の問題が発生します。ブラウザはXMPP over Transmission Control Protocol(TCP)をネイティブでサポートしていないため、すべてのXMPPトラフィックはブラウザ内で動作するプログラムで処理する必要があります。WebサーバおよびブラウザはHyperText Transfer Protocol(HTTP)メッセージを介して通信するため、Finesseおよび他のWebアプリケーションはHTTPメッセージ内でXMPPメッセージをラップします。
このアプローチの最初の問題は、HTTPがステートレスプロトコルである点です。これは、各HTTP要求が他の要求に関連していないことを意味します。ただし、この問題は、クッキーやポストデータの使用など、適切な方法で対処できます。
2つ目の問題は、HTTPの単方向動作です。クライアントだけが要求を送信し、サーバは応答のみ可能です。サーバがデータをプッシュできないため、HTTPでXMPPを実装するのは不自然です。
この問題は、XMPPがTCPにバインドされている元のXMPPコア仕様(RFC 6120)には存在しません。ただし、HTTPにバインドされたXMPPの問題に対処する必要がある場合、たとえばJavascriptがHTTP要求を送信できるため、2つの解決策があります。どちらもHTTPとXMPP間のブリッジが必要です。
提案するソリューションは次のとおりです。
1.ポーリング(レガシープロトコル):XEP-0025で定義された新しいデータを要求するHTTP要求を繰り返します。Jabber HTTPポーリング
2.ロングポーリングはBOSH:XEP-0124で定義されている頻繁なポーリングを使用することなく、複数の同期HTTP要求/応答ペアを効率的に使用して、2つのエンティティ間の長寿命の双方向TCP接続のセマンティックをををエミュレートするプロトコル。XEP-0206によって拡張されたHTTPバインディング:XMPP over BOSH
FinesseはBOSHを実装します。これは、サーバの負荷の観点から見ると非常に効率的であり、トラフィックに関しては非常に効率的です。BOSHを使用する目的は、要求があるとすぐにサーバが応答する必要がないという事実をカバーすることです。応答は、サーバがクライアントのデータを取得するまで指定された時間まで遅延され、応答として送信されます。クライアントが応答を受信すると、クライアントは新しい要求などを行います。
Finesseデスクトップクライアント(Webアプリケーション)は、30秒ごとにTCPポート7443で古いBOSH接続を確立します。30秒後、Finesse Notification Serviceからの更新がない場合、Notification Serviceは200 OKと(ほぼ)空の応答本文を含むHTTP応答を送信します。たとえば、エージェントまたはダイアログ(コール)イベントの存在に関する更新が通知サービスに含まれている場合、データはただちにFinesse Webクライアントに送信されます。
次の例は、FinesseクライアントとFinesseサーバ間で共有され、BOSH接続を設定する最初のXMPPメッセージ要求応答を示しています。
Finesse client request:
<body xmlns="http://jabber.org/protocol/httpbind" xml:lang="en-US" xmlns:xmpp="urn:xmpp:xbosh" hold="1" ver="1.9" to="fin1.ucce.local" wait="30" xmpp:version="1.0" from="47483648@fin1.ucce.local" rid="704654808"/>
Finesse server response:
<body xmlns="http://jabber.org/protocol/httpbind" xmlns:stream="http://etherx.jabber.org/streams" authid="26779701" sid="26779701" secure="true" requests="4" inactivity="60" polling="5" wait="30" hold="1" ack="704654808" maxpause="300" ver="1.6"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features></body>
まとめ
FinesseはXMPP仕様XEP-0060:Publish-Subscribe。この仕様の目的は、XMPPサーバ(通知サービス)がXMPPノード(トピック)に公開された情報を取得し、そのノードに登録されているエンティティにXMPPイベントを送信できるようにすることです。Finesseの場合、Computer Telephony Integration(CTI)サーバはFinesse WebサービスにCTIメッセージを送信して、エージェントやコンタクトサービスキュー(CSQ)の作成やコールに関する情報などの設定の更新についてFinesseに通知します。この情報は、Finesse WebサービスがFinesse Notificationサービスに発行するXMPPメッセージに変換されます。Finesse通知サービスは、特定のXMPPノードにサブスクライブされているエージェントにBOSHメッセージを介してXMPPを送信します。
『Finesse Web Services Developer Guide』で定義されているFinesse APIオブジェクトの一部はXMPPノードです。エージェントおよびスーパーバイザのFinesse Webクライアントは、これらのXMPPノードの一部のイベントアップデートをサブスクライブして、リアルタイムイベント(コールイベント、状態イベントなど)に関する最新情報を取得できます。 次の表に、pubsubが有効になっているXMPPノードを示します。
Finesse APIオブジェクト | 目的 | サブスクリプション |
/finesse/api/User/<LoginID> | エージェントの状態とチームのマッピングを表示します | エージェントとスーパーバイザ |
/finesse/api/User/<LoginID>/Dialogs |
エージェントが処理しているコールを表示します。 | エージェントとスーパーバイザ |
/finesse/api/User/<LoginID>/ClientLog |
[エラーレポートの送信]ボタンからクライアントログをキャプチャするために使用します | エージェントとスーパーバイザ |
/finesse/api/User/<LoginID>/Queue/<queueID> |
キュー統計データを表示します(有効の場合) | エージェントとスーパーバイザ |
/finesse/api/Team/<TeamID>/Users |
特定のチームに属するエージェントを表示します(状態情報を含む) | スーパーバイザ |
/finesse/api/SystemInfo |
Finesseサーバの状態を表示します。フェールオーバーが必要かどうかを判断するために使用します。 | エージェントとスーパーバイザ |
ステップ1:XMPPクライアントピジンをダウンロードしてインストールします。
ステップ2:[Accounts] > [Modify] > [Basic]に移動し、ログインオプションを設定します。
ステップ3:[Accounts] > [Modify] > [Advanced]に移動し、次のように設定します。
注:ポート5222が使用されるのは、Finesse Webクライアントだけがポート7443を使用して通知サービスに接続できるためです。
ステップ4:[Tools] > [Plugins]に移動し、XMPPコンソールを有効にします。
ステップ5:[Tools] > [XMPP Console] > [XMPP Console]に移動してXMPPコンソールを開きます。
ステップ6:この<iq> メッセージを実行して、存在するすべてのXMPPノードを表示します。
例:
2つのエージェントと2つのCSQが設定されたラボ環境では、次の出力がFinesse応答に含まれています。
各ブラウザには、一連の開発者ツールがあります。開発者ツールのNetworkタブには、Finesse Webクライアント(ブラウザ)によって送受信されるHTTPメッセージが表示されます。 たとえば、次の図は、Finesse WebクライアントがSystemInfo要求を送信する方法を示しています。この要求は、フェールオーバーチェックとしてFinesse Tomcatのステータスを毎分チェックします。また、BOSH接続からのhttp-bindメッセージも表示されます。Finesseサーバは、WebクライアントがサブスクライブされているXMPPノードで発行する更新がない場合に、30秒以内に応答を返信します。
BOSH切断が発生すると、「Lost connection to {Finesse Server FQDN}」というエラーが表示されます。Please wait for a reachable Finesse Server to be found...」というメッセージが、Finesseデスクトップの上部に赤いバナーで表示されます。
このメッセージは、Cisco Finesse Notification ServiceからXMPPサブスクリプションイベントを受信できないため表示されます。したがって、エージェントのデスクトップに状態情報とコールの詳細を表示することはできません。
UCCXの場合、ブラウザの接続が解除されてから60秒後、エージェントはログアウト状態になります。エージェントは、ログアウトを実行するためにReadyまたはNot Ready状態にできます。
UCCEでは、エージェントがブラウザを閉じるか、ブラウザがクラッシュするとFinesseが60秒間待機してからCTIサーバに強制ログアウト要求を送信し、CTIサーバがエージェントをNot Ready状態にします。これらの状況では、Finesseはエージェントのログアウトに最大180秒かかることがあります。UCCXとは異なり、エージェントはログアウト状態ではなくNot Ready状態に移行します。
注:UCCEでのCTI切断のNot ReadyとLogout状態の動作は、PG /LOADパラメータによって制御されます。Unified Contact Center EnterpriseおよびHostedリリース10.0(1)のリリースノートに従って、/LOADパラメータはUCCE 10.0以降で廃止されます。
UCCE Finesseデスクトップの動作の詳細については、『Cisco Finesseアドミニストレーションガイド』の「Cisco Finesseフェールオーバーメカニズム」の章の「デスクトップの動作」セクションを参照してください。
注:タイマー値は、製品の要件に従って将来的に変更される可能性があります。
FinesseおよびUCCX通知サービスログは、RTMTまたはCLIから収集できます。
file get activelog /desktop recurs compress
注:問題の再生中にのみデバッグレベルのログを設定します。問題の再現後にデバッグをオフにします。
注:Finesse 9.0(1)にはデバッグレベルのロギングはありません。デバッグレベルのロギングはFinesse 9.1(1)で導入されました。 ロギングを有効にするプロセスは、Finesse 10.0(1) ~ 11.6(1)とは9.1(1)で異なります。 このプロセスについては、『Finesse Administration and Serviceability guide』を参照してください。
次に示すように、Unified Contact Center Express(UCCX)の通知サービスデバッグログを有効にします。
admin:utils uccx notification-service log enable
WARNING! Enabling Cisco Unified CCX Notification Service logging can affect system performance
and should be disabled when logging is not required.
Do you want to proceed (yes/no)? yes
Cisco Unified CCX Notification Service logging enabled successfully.
NOTE: Logging will be disabled automatically if Cisco Unified CCX Notification Service is restarted.
次に示すように、Unified Contact Center Enterprise(UCCE)(Finesse Standalone)の通知サービスデバッグログを有効にします。
admin:utils finesse notification logging enable
Checking that the Cisco Finesse Notification Service is started...
The Cisco Finesse Notification Service is started.
Cisco Finesse Notification Service logging is now enabled.
WARNING! Cisco Finesse Notification Service logging can affect system performance
and should be disabled when logging is not required.
Note: Logging will be disabled automatically if you restart the Cisco Finesse Notification Service
これらのログは/desktop/logs/openfireフォルダにあり、debug.logという名前です。
図に示すように、通知サービス(Openfire)debug.logは、エージェントPCのIPアドレスとポートに加えて、デスクトップとのHTTPバインディングを表示します。
図に示すように、最後のアクティブ0ミリ秒はセッションがまだアクティブであることを示します。
Openfireがアイドルセッションを閉じると、エージェントログアウトが60秒後にトリガーされ、Finesseは理由コード255の強制ログアウトをCTIサーバに送信します。これらの条件下でのデスクトップの実際の動作は、UCCEの[Logout on Agent Disconnect (LOAD)]の設定によって異なります。UCCXでは、これは常に動作です。
Finesseクライアントがhttp-bindメッセージをFinesseサーバに送信しない場合、ログにはセッションアップタイムとセッションクローズが表示されます。
2017.06.17 00:14:34 Session (id=f382a015) was last active 0 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:15:04 Session (id=f382a015) was last active 13230 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:15:34 Session (id=f382a015) was last active 43230 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:16:04 Session (id=f382a015) was last active 63231 ms ago: 1001003@xxxxx.xxxx.xxx.cisco.com/desktop 2017.06.17 00:17:04 Unable to route packet. No session is available so store offline. <message from="pubsub. xxxxx.xxxx.xxx.cisco. com" to="1001003@xxxxx.xxxx.xxx.cisco.com.cisco.com" id="/finesse/api/User/1001003__1001003@xxxxx.xxxx.xxx.cisco.com__o5Aqb"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="/finesse/api/User/1001003"><item id="0d78a283-466d-4477-a07e-6e33a856fce388"><notification xmlns="http://jabber.org/protocol/pubsub"><Update>
これらのログは/desktop/logs/openfireフォルダにあり、info.logという名前です。Finesseクライアントがhttp-bindメッセージをFinesseサーバに送信しない場合、ログにはセッションが非アクティブになったことが示されます。
2017.06.17 00:16:04 Closing idle session (id=f382a015): 1001003@xxxxx.xxxx.xxx. cisco.com/desktop after being inactive for more than threshold value of 60 2017.06.17 00:16:04 A session is being closed for 1001003@xxxxx.xxxx.xxx. cisco.com/desktop
これらのログは/desktop/logs/webservicesフォルダにあり、Desktop-webservices.YYYY-MM-DDTHH-MM-SS.sss.logという名前です。Finesseクライアントが指定された時間内にhttp-bindメッセージをFinesseサーバに送信しない場合、エージェントのが使用不能が6になる0秒後、ライセンス駆動型ログアウトが発生します。
0000001043: XX.XX.XX.XXX: Jun 17 2017 00:16:04.630 +0530: %CCBU_Smack Listener Processor (1)-6-PRESENCE_NOTIFICATION_RECIEVED: %[FROM JID=1001003@xxxxx.xxxx.xxx.cisco.com/desktop][PRESENCE_TYPE=unavailable]:Finesse received a presence notifcation 0000000417: XX.XX.XX.XXX: Jun 17 2017 00:16:04.631 +0530: %CCBU_Smack Listener Processor (1)-6-UNSUBSCRIBE_REQUEST_SUCCESS: %[NodeId=/finesse/api/User/1001003/ClientLog][user_id=1001003@xxxxx.xxxx.xxx.cisco.com]: Sucessfully unsubscribed from a node on the XMPP server 0000001044: XX.XX.XX.XXX: Jun 17 2017 00:16:04.631 +0530: %CCBU_Smack Listener Processor (1)-6-AGENT_PRESENCE_MONITOR: %[message_string=Adding agent 1001003 into the expiry hash.]: 0000001051: XX.XX.XX.XXX: Jun 17 2017 00:16:35.384 +0530: %CCBU_pool-8-thread-1-6-AGENT_PRESENCE_MONITOR: %[message_string=[Expired] Removed agent from cache 1001003]: 0000001060: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.632 +0530: %CCBU_CoreImpl-worker12-6-PRESENCE DRIVEN LOGOUT: %[agent_id=1001003]: Performing CTI Logout on basis of the agents unavailable presence 0000001061: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.633 +0530: %CCBU_CoreImpl-worker12-6-MESSAGE_TO_CTI_SERVER: %[cti_message=Invoke id :39 , agentstate : 1, workmode : 0, reason code: 255, forceflag :1, agentcapacity: 1, agentext: 1001003, agentid: 1001003, supervisorid: null, ssoFlag=false][cti_message_name=SetAgentStateReq]: Message going to the backend cti server 0000001066: XX.XX.XX.XXX:: Jun 17 2017 00:17:04.643 +0530: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=1 (LOGOUT), stateDuration=0, skillGroupNumber=-1, skillGroupPriority=0, agentState=1 (LOGOUT), eventReasonCode=255, numFltSkillGroups=0, CTIClientSignature=null, agentID=1001003, agentExtension=1001003, agentInstrument=null, agentID_Long=1001003, duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[], MRDId=1, agentMode=0]CTIMessageBean [invokeID=null, cti_sequence_id=105, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1497638824642,"CTI_MSG_DISPATCH":1497638824643}, msgName=AgentStateEvent, deploymentType=CCX]][cti_response_time=1][dispatch_phase=DnD-CHECKPOINT-3B]: Decoded Message to Finesse from backend cti server
BOSH接続はWebクライアントによって設定され、Finesseサーバによってエージェントプレゼンスが使用できないかどうかが判断されます。これらの問題は、接続を開始する際にクライアントに対して問題が発生するため、ブラウザ、エージェントコンピュータ、またはネットワークに関連するクライアント側の問題です。
次の問題を確認してください。
1.ネットワークの問題:
クライアントは1分ごとにFinesseサーバに接続し、ドリフトとネットワーク遅延を計算します。
<PC date-time with GMT offset>: : <Finesse FQDN>: <Finesse server date-time with offset>: Header : Client: <date-time>, Server: <date-time>, Drift: <drift> ms, Network Latency (round trip): <RTT> ms
2019-01-11T12:24:14.586 -05:00: : fin1.ucce.local: Jan 11 2019 11:24:14.577 -0600: Header : Client: 2019-01-1
2.サポートされていないブラウザまたはバージョン:
互換性マトリクスに従って、サポートされているブラウザ/バージョンと設定を使用します。
3.他のタブ/ウィンドウの内容/処理によるブラウザのスタック状態:
エージェントワークフローを確認して、次の内容が表示されるかどうかを確認します。
4.コンピューターをスリープ状態にする:
エージェントがFinesseからログアウトする前にコンピュータをスリープ状態にするか、またはコンピュータスリープ設定タイマーが非常に低いかを確認します。
5.クライアントコンピュータのCPUの高使用率またはメモリの高使用率:
6.バックグラウンドで予期しない問題のあるアクティビティを実行するサードパーティ製ガジェット:
すべてのサードパーティガジェットを削除して、Finesseデスクトップの動作をテストします。
7.サーバまたはクライアントのNTP問題:
次の問題を確認してください。
1. Cisco Unified Communications Manager CTIManagerサービスの接続解除。UCCXのすべてのCTIManagerプロバイダがシャットダウンまたはクラッシュした場合、UCCXエージェントは赤色のバナーエラーを表示します。これが発生すると、UCCEエージェントには赤いバナーが表示されませんが、コールはエージェントに適切にルーティングされません。
注:コアダンプファイル名の形式は、core.<ProcessID>.<SignalNumber>.<ProcessName>.<EpochTime>です。
例:core.24587.6.CTIManager.1533441238
したがって、クラッシュの時刻はエポック時刻から決定できます。
2. Finesse/UCCX Notification Serviceが停止したか、クラッシュしました。
クラッシュが疑われる場合は、Cisco Finesse Tomcatおよび通知サービスを再起動します。これはネットワークダウン状況でのみ推奨されます。そうしないと、Finesseサーバから切断エージェントが再起動されます。
Fiddlerの設定は、必要な手順を理解し、Fiddlerの動作を理解しなくても、ある程度困難な作業になります。Fiddlerは、Finesseクライアント(Webブラウザ)とFinesseサーバの間に存在するman-in-the-middle Webプロキシです。FinesseクライアントとFinesseサーバ間の接続が保護されているため、Fiddlerの設定に複雑なレイヤが追加され、保護されたメッセージが表示されます。
FiddlerはFinesseクライアントとFinesseサーバの間に存在するため、Fiddlerアプリケーションは、証明書を必要とするすべてのFinesse TCPポートの署名付き証明書を作成する必要があります。
Cisco Finesse Tomcatサービス証明書
Cisco Finesse(Unified CCX)Notification Service証明書
FiddlerがFinesseサーバの代わりに証明書を動的に生成するには、HTTPS復号化を有効にする必要があります。これはデフォルトでは有効になっていません。
HTTPS復号化が設定されていない場合、通知サービスへの最初のトンネル接続は表示されますが、http-bindトラフィックは表示されません。Fiddlerは次のみを表示します。
Tunnel to <Finesse server FQDN>:7443
次に、Fiddlerによって署名されたFinesse証明書は、クライアントによって信頼されている必要があります。これらの証明書が信頼されていない場合は、暗号化された接続を確立する… Finesseログインの段階を越えて移動することはできません。
場合によっては、ログインからの証明書例外の受け入れが機能せず、ブラウザで証明書を手動で信頼する必要があります。
注意:提供されている設定例は、ラボ環境のWindows 7 x64上の.NET 4.5用のFiddler v5.0.20182.28034およびMozilla Firefox 64.0.2(32ビット)用です。これらの手順は、すべてのバージョンのFiddler、すべてのブラウザ、またはすべてのコンピュータのオペレーティングシステムに一般化されない場合があります。ネットワークが稼働中の場合は、構成の潜在的な影響を理解してください。詳細は、Fiddlerの公式ドキュメントを参照してください。
ステップ1: Fiddlerのダウンロード
ステップ2:HTTPS復号化を有効にします。[Tools] > [Options] > [HTTPS] > [Decrypt HTTPS traffic]チェックボックスをオンにします。
ステップ3:Fiddlerルート証明書を信頼するように求める警告メッセージボックスが表示されます。[はい]を選択します。
ステップ4:警告メッセージボックスが開き、「You are about to install a certificate from a certification authority (CA) claiming to be pricing:DO_NOT_TRUST_FiddlerRoot...この証明書をインストールしますか?" [Yes] を選択します。
ステップ5:Finesseパブリッシャおよびサブスクライバ証明書をコンピュータまたはブラウザの証明書信頼ストアに手動で追加します。ポート8445、7443、および(UCCEのみ)443を確認します。たとえば、Firefoxの場合は、[Finesse Operating System Administration]ページから証明書をダウンロードせずに実行できます。
[Options] > [Find in Options (search)] > [Certificates] > [Servers] > [Add Exception] > [Location] > [Enter https://<Finesse server>:port for the relevant ports for the both Finesse servers.]
ステップ6:Finesseにログインし、http-bindメッセージがFinesseクライアントからFiddler経由でFinesseサーバに残ることを確認します。
この例では、最初の5つのメッセージはFinesseサーバから応答されたhttp-bindメッセージを示しています。最初のメッセージには、メッセージ本文で返された1571バイトのデータが含まれています。本文には、エージェントイベントに関するXMPPアップデートが含まれています。最後のhttp-bindメッセージはFinesseクライアントによって送信されましたが、Finesseサーバから応答を受信していません。これは、HTTPの結果がnull(-)で、応答の本文のバイト数がnull(-1)であることを確認することで判断できます。
データの詳細:
XMPPメッセージの応答本文:
Wiresharkは、HTTPSトラフィックのスニフィングとデコードに使用できる、よく使用されるパケットスニフィングツールです。HTTPSトラフィックは、Transport Layer Security(TLS)で保護されるHTTPトラフィックです。TLSは、ホスト間の整合性、認証、および機密性を提供します。これはWebアプリケーションで一般的に使用されますが、トランスポート層プロトコルとしてTCPを使用する任意のプロトコルで使用できます。Secure Sockets Layer(SSL)はTLSプロトコルの旧バージョンで、安全でないために使用されなくなりました。これらの名前は頻繁に同じ意味で使用され、SSLまたはTLSトラフィックに使用されるWiresharkフィルタはsslです。
注意:この設定例は、ラボ環境のWindows7 x64上のWireshark 2.6.6(v2.6.6-0-gdf942cd8)およびMozilla Firefox 64.0.2(32ビット)用です。これらの手順は、すべてのバージョンのFiddler、すべてのブラウザ、またはすべてのコンピュータのオペレーティングシステムに一般化されない場合があります。ネットワークが稼働中の場合は、構成の潜在的な影響を理解してください。詳細は、公式のWireshark SSLドキュメントを参照してください。Wireshark 1.6以上が必要です。
注:この方法は、FirefoxおよびChromeでのみ機能します。この方法はInternet Explorerでは機能しません。
ステップ1:エージェントのWindows PCで、[Control Panel] > [System and Security] > [System] > [Advanced system settings] [Environmental Variables...]に移動します。
ステップ2:ユーザのユーザ変数<username> > [New...]に移動します。
SSLKEYLOGFILEという名前の変数を作成します。
SSLプレマスターシークレットをプライベートディレクトリに保存するファイルを作成します。SSLKEYLOGFILE =</path/to/private/directory/with/logfile>
注:ユーザ変数の代わりにシステム変数を作成したり、ファイルをプライベート以外のディレクトリに保存したりすることも可能ですが、システム上のすべてのユーザがプレマスターシークレットにアクセスでき、安全性が低くなります。
ステップ3:FirefoxまたはChromeが開いている場合は、アプリケーションを閉じます。ファイルが再オープンされると、SSLKEYLOGFILEへの書き込みが開始されます。
ステップ4:Wiresharkで、[Edit] > [Preferences...]に移動します。
[Protocols] > [SSL]に移動します。
ステップ5:ステップ2で設定したプレマスターシークレットログファイル名の場所を入力します。
ステップ6:Wiresharkフィルタtcp.port==7443 && sslを使用すると、Finesseクライアント(通知サービス)とFinesseサーバ(通知サービス)間のセキュアなHTTP通信が復号化されて表示されます。