リリース共通の警告
ここでは、すべての JTAPI リリースに共通する警告を示し、次のトピックについて説明します。
単一と複数の CallObserver について
Cisco JTAPI の CallObserver でアドレスを監視するには、主に 2 つの方法があります。アプリケーションで 1 つの CallObserver オブジェクトを使用してすべてのアドレスを監視する方法と、各アドレスに対して別の CallObserver オブジェクトを使用する方法です。この 2 つのアプローチでは、主に原因コードに関連して、参照されるイベントが少し異なります。
アプリケーションで、1 つの CallObserver を使用してすべてのアドレスを監視する場合、アドレスは 1 つのオブジェクトで接続されます。A が B をコールする場合、A と B の両方にあるイベントが、同じ CallObserver オブジェクトに送信されます。B が C にリダイレクトされ、C が同じオブジェクトで監視される場合、そのすべてのイベントが同じオブザーバに配信されます。C のオブザーバは、コールの前のイベントに関するすべてについて認識しているため、アプリケーションでは、原因 REDIRECT で C に対する CallCtlConnOfferedEv が監視されます。
逆に、アプリケーションで、各アドレスに対して個別の CallObserver を使用する場合、この情報はそれほど簡単には共有されません。A が B をコールする場合、A のコール イベントは A のオブザーバに配信され、B のコール イベントは B のオブザーバに配信されます。それぞれのオブザーバでは相手側を認識します(たとえば、A は B が呼び出し中であることを認識します)が、同じオブザーバではありません。B がコールを C にリダイレクトすると、C のオブザーバは、コールについては何も認識しません。C のオブザーバは、元のコールにまったく含まれていなかったため、コールの参加者についても、前に起こったイベントについても、認識しません。C に正確なコール モデルを構築するには、JTAPI によりこの情報を生成する必要があります。C の観点からコール モデルが理にかなうようにするには、A と B との間の基本コールのすべてのコール イベントをシミュレーションする必要があります。
これは、スナップショット イベントを使用して行われます。JTAPI でコールが参照されます。この場合は A と B との間のコールが参照され、コールが現在のように存在するためには、どのイベントが発生する必要があるかが、判断されます。必要な基本コール イベントが構築され、C にあるオブザーバに渡され、これによって、適切なコール モデルを構築できます。
このイベント セットは JTAPI によって構築されているため、原因コードは使用できません。たとえば、まず A が D をコールし、D が B にリダイレクトされた場合、構築されるスナップショット イベント セットでは、リダイレクトはまったく考慮されません。JTAPI では、この情報はいずれの場所にも保存されません。JTAPI でスナップショットが生成されるときに、コール モデルを再作成できる最も簡素なイベント セットが作成され、すべてのイベントが原因 NORMAL で報告されます。
そのため、A が B をコールし、その後、B が C にリダイレクトした場合、C のオブザーバはスナップショット イベントを取得し、これにより、A から B への基本コールのコール モデルを再作成することができます。このスナップショット イベントには、C への CallCtlConnOfferedEv も含まれます。このイベントは、リダイレクトの結果であっても、スナップショットの一部として原因 NORMAL で生成されます。A または B の CallObserver では、原因 REDIRECT で C に対する CallCtlConnOfferedEv が参照されますが、C のオブザーバがこれを認識する方法はありません。
これにより、CallObserver の実装方法によって、アプリケーションで使用可能な原因コードでの通知可能な違いが作成されます。これについては、ユーザ側からの問題はありません。
これは、Cisco JTAPI の代行受信以降の方法で、既存動作の確認です。
重複電話番号パターンでの SIP と SCCP のダイヤルの違い
重複電話番号パターンは、1 つの電話番号が、それより長い電話番号の一部になっているときに発生します。たとえば、電話番号 1000 は、電話番号 10001 と重複しています。Cisco Unified Communications Manager(Cisco Unified CM)と JTAPI の両方で、重複電話番号がサポートされますが、これについては、いくつかの注意点があります。
通常の電話機から 1000 にダイヤルすると、遅延が発生します。Cisco Unified CM では、1000 にダイヤルするのか 10001 にダイヤルするのかが認識されないため、ユーザによる選択を待ちます。このディジット アナライザは、ユーザが何も押さなかった場合、15 秒間待機します。この時間の間、何も起こらず、コールは拡張されず、発信側では未反応コールのように聞こえます。これは、# を押すことによる回路短絡の可能性があり、Cisco Unified CM では、実際には 1000 を呼び出すことを意図していることが認識されます。この 15 秒間の待機は、T302 Timer という設定可能なサービス パラメータで、最短で 3 秒に設定できます。
SCCP 電話機を使用している JTAPI では、Cisco Unified CM と直接通信することによってディジット アナライザが完全に回避されます。JTAPI では、発信時に意図する電話番号を送信します。1000 が送信される場合、Cisco Unified CM では、これより多い桁はダイヤルされません。
SIP 電話機を使用している JTAPI では、動作はかなり異なります。JTAPI は電話機との通信を行い、次に、Cisco Unified CM と通信します。電話機でダイヤルが実行され、JTAPI により、桁 1000 が渡されてダイヤルされます。このため、JTAPI ではディジット アナライザが回避できず、前述のような T302 での待機が前提となります。SIP 電話機が実際に 1000 にダイヤルすることを、ディジット アナライザで確認する間、JTAPI は、アイドル状態で待機します。
これとは別に、JTAPI CTI Postcondition 値も、デフォルトで 15 秒に設定されています。これは、JTAPI が、CTI レイヤに要求を送信するときに、動作が正常ではないと判断する前に 15 秒間待機してからタイムアウト例外をスローすることを意味します。これは、重複 DN パターンに対するディジット アナライザの遅延により、JTAPI でタイムアウトが発生する可能性が高いことを意味します。
ディジット アナライザの遅延は、SIP 電話機から完全になくすことはできませんが、この問題は、サービス パラメータまたは jtapi.ini パラメータを使って大幅に軽減できます。前述のとおり、ディジット アナライザの T302 Timer は、最短で 3 秒に設定できます。これは JTAPI がタイムアウトする 15 秒に比べるとかなり短い時間です。jtapi.ini ファイルでは、JTAPI CTI Postcondition タイムアウトも最大 20 秒まで増やすことができます。この問題は、重複 DN がない状態にすることによっても、回避できます。
トランスレーション パターンのサポート
JTAPI アプリケーションが制御するアドレスに適用されているトランスレーション パターンに対して発呼側変換マスクを設定すると、発信側と着信側の両方を監視している場合、アプリケーションは余分な Connection の作成および Connection 解除を認識されます。アプリケーションが着信側だけを監視している場合、変換された発信側に対して Connection が作成され、CiscoCall.getCurrentCallingParty() は変換された発信側アドレスを返します。一般的に、JTAPI には適切な CallConnection を作成するうえで問題があり、currentCalling、currentCalled、calling、called、および lastRedirecting の通話者などの正確な CallInfo が提供されない可能性があります。たとえば、トランスレーション パターン X で、発呼側変換マスク Y と着信側変換マスク B が設定されているとします。A が X をコールすると、コールは B に着信します。この場合、次のようになります。
-
アプリケーションが B だけを監視している場合、JTAPI は Y と B に対して Connection を作成し、CiscoCall.getCurrentCallingParty() は Address Y を返します。
-
アプリケーションが A と B の両方を監視している場合、A と B に対して Connection が作成され、Y に対して Connection が一時的に作成されて破棄され、CiscoCall.getCurrentCallingParty() は Address Y を返します。
基本的なコールに対して他の機能も実行すると、これ以外にも CallInfo の不統一が発生する可能性があります。JTAPI アプリケーションが制御するアドレスに適用される可能性のあるトランスレーション パターンに対しては、発呼側変換マスクを設定しないことが推奨されます。
PRI NI2 トランクでの DT24 + 制限
クラスタ 1 の A が DT24+ PRI NI2 トランクを介してクラスタ 2 の B にコールする場合など、DT24+ ゲートウェイで使用される PRI NI2 トランクが 2 つのクラスタ間のコール シナリオに含まれる場合、B の側の LastRedirectAddress および CalledAddress が正確でない可能性があります。さらに、リダイレクト、送信、または転送により、クラスタ 1 のコールの A 側に変更があった場合、PRI NI2 トランクのプロトコル制限のため、B 側には変更された情報が伝播されません。
パーク番号に対する接続が作成されない
コールがゲートウェイでパークされている場合、JTAPI では、パーク番号に対して Queued 状態の Connection は作成されません。ここでは、次の 2 つの可能性があります。
-
CLI が設定されている場合、アプリケーションで Unknown Connection が確認される。
-
CLI が設定されていない場合、発信側では Unknown Connection は確認されない。
たとえば、A がゲートウェイを介して B にコールし(CLI が設定されている状態)、B がそのコールをパークすると、A ではパーク番号に対する Connection(STATE = QUEUED)ではなく Unknown Connection が確認されます。
ただし、A がゲートウェイを介して B にコールし(CLI が設定されていない状態)、B がコールをパークすると、A では新規の Connection は確認されません。
SIP 電話機と SCCP 電話機間の不一致
電話機にデータを送信するには、CiscoTerminal で sendData() API を使用します。SIP 電話機の場合、アプリケーションによって無効なバイト データが送信されると、メソッドが PlatformException をスローします。ただし、SCCP 電話機の場合は、要求で送信されたバイト データは検証されず、例外がスローされることなく正常に終了します。
宛先間でのコール ルーティングの失敗
コールがアウト オブ サービスの H323 ゲートウェイを介してクラスタ外のデバイスにリダイレクトされると、コール制御で H323 ゲートウェイの Out-of-Service ステータスが判断される前に、コールが接続解除されます。これは、ゲートウェイがアウト オブ サービスであることをコール制御で判断するのに 5 秒かかるのに対し、CTI NewCallAccept timer サービス パラメータのデフォルト値が 4 秒であり、コールが CTI NewCallAccept タイムアウトの期限切れによって接続解除されるためです。
上記の動作は、コールをルーティングする CTI redirect API を内的に使用する JTAPI selectRoute() API に関連しています。アプリケーションで selectRoute() に複数の宛先が指定されており、最初の宛先がアウトオブサービスの H323 ゲートウェイを経由する場合、JTAPI が 2 番めの宛先にコールをルーティングする前にコールは失敗します。そのため、JTAPI では selectRoute() インターフェイス コールに指定された 2 番めのルートにコールをルーティングできません。
この問題を回避するには、CTI New Call Accept Timer サービス パラメータの値を H225 TCP Timer サービス パラメータの値より大きくします。
getCallingAddress() に対する不正確な戻り値
発信側と transferController が監視されていない、つまり A が B をコールし、そのコールを C に転送する場合にアプリケーションが C だけを監視している転送シナリオでは、転送の前に、JTAPI に最初のコール(A から B へのコール)に関する情報が存在しません。したがって、転送機能を呼び出すと、発信側アドレスと着信側アドレスはそれぞれ B と C になります。転送が終了すると、アプリケーションによって callInfo が更新され、JTAPI では getCurrentCallingAddress()、getCurrentCalledAddress()、getModifiedCallingAddress()、および getModifiedCalledAddress() によって正確な通話者が表示されます。ただし、元の発信側アドレスを返す getCallingAddress() API は B を報告します。つまり、C へのコールの元の発信側は B となります。
この問題を回避するには、アプリケーションでコントローラも一緒に監視し、JTAP で getCallingAddress() API によって正確な通話者(この場合は A)を表示できるようにします。
共用回線を保有するコールを接続解除できない
A が B をコールするシナリオで(B は端末 T1 と T2 に存在する共用回線)、T1 のプライバシーが ON に設定され、保留中のコールに対する CUCM サービス パラメータ Enforce Privacy Settings が最初に True に設定されているとします。B(T1)が応答し、Talking 状態になると、B(T2)は Passive 状態(TermConn=Passive、CallCtlTermConn = InUse)になります。B(T1)がコールを保留すると、保留中のコールに対する Enforce Privacy Setting が True に設定されているので、B(T2)は Passive 状態(TermConn=Passive、CallCtlTermConn = InUse)のままになります。ここで、保留中のコールに対する Enforce Privacy Settings サービス パラメータを False に設定します。この設定で TerminalConnection の状態が変化することはなく、B(T2)は Passive-InUse(TermConn=Passive、CallCtlTermConn = InUse)のままとなります。この時点で、アプリケーションで requestController を B(T1)に設定し、B でコールの接続を解除すると、B の Connection は解除されず、コールは IDLE になりません。電話機でも、A ではコールが Established 状態であるのに対し、コールの相手側である B(T2)は Passive-InUse(TermConn=Passive、CallCtlTermConn = InUse)状態のままとなります。A がコールを接続解除すると、コールはクリアされます。
CiscoTerminal で sendData() API を使用する場合の制限
JTAPI アプリケーションが、要求間の遅延なしで同じ CiscoTerminal の sendData() API に対する複数の要求に同時に応答すると、一部の要求は失敗する可能性があります。アプリケーションでは要求が成功したかどうかを判断できず、Cisco JTAPI API は、電話機がデータを受信した時点で電話機からの応答を待たずに正常に終了します。また、IP フォンでは、同時要求を送信するときに空白画面を表示してデータを送信する場合があります。
これらの問題を回避するには、JTAPI アプリケーションで連続する 2 つの sendData() 要求の間にある程度の遅延時間を確保し、XSI データが Cisco JTAPI 経由で IP 電話機にプッシュされるようにします。
ユーザ ID とパスワードに「;」(セミコロン)と「=」(等号)を使用する場合の制限
getProvider() メソッドでパラメータとして使用される文字列で、Host Name フィールド、UserID フィールド、および Password フィールドを生成するときに、Sun JTAPI 1.2 仕様では、セミコロン(;)および等号(=)の使用はサポートされません。これらのフィールドで「;」や「=」を使用した場合、たとえば「pass=word」や「pass;word」などは、「pass」として扱われ、要求が失敗する可能性があります。したがって、UserID フィールドや Password フィールドでは、これらの文字は使用しないでください。
電話会議のパーク解除時の、未知のアドレスへの接続
電話会議がパークされている場合、JTAPI コールはコール内の残りの参加者に接続できます。このコールがパーク解除 API または接続 API を使用してパーク解除された場合、未知のアドレスへの接続が一時的に作成されます。未知のアドレスへのこの接続は、パーク解除が完了するときに切断されます。
次の内容が、JTAPI トレースに示されます。
2002 : (P1-InProv) 103023/1 ConnCreatedEv Unknown:null:4 187 Cause:100 CallCtlCause:0 CiscoCause:31 FeatReason:10 CAUSE_NORMAL
....
2002 : (P1-InProv) 103023/1 ConnDisconnectedEv Unknown:null:4 187 Cause:100 CallCtlCause:0 CiscoCause:31 FeatReason:10 CAUSE_NORMAL
ボイス メールへの CTI リダイレクトが QSIG で動作しない
アプリケーションが QSIG トランクを介してボイス メールにコールをリダイレクトすると、ボイス メールはリダイレクトした通話者の音声プロンプトを再生しません。ボイス メール ボックスを入力するようにユーザに求める汎用プロンプトが表示されます。これは、CTI リダイレクトが、正しい元の着信者とリダイレクトした通話者をボイス メール システムに渡さないためです。アプリケーションは、SIP トランクを使用することでこれを回避できます。
電話機 A が電話機 B(デスクフォン モードの CUCILYNC)をコールします。「エンベロープ」の Toast ポップアップが着信コールに対して表示されます。
ユーザはエンベロープをクリックし、QSIG トンネリングを使用して、H.323 トランク経由でコールをリダイレクトします。Unity/Unity Connection は元の着信者を認識しないので、コールはユーザのボイス メールボックスに入りません。これは、CTI リダイレクトの使用時に、リダイレクトした通話者/元の着信者の情報がトランク経由で伝送されないためです。
イン サービスのアドレスにのみ正しい値を返す CiscoAddress.getForwarding()
SIP 電話機でサポートされない CTI イベント
次の CTI イベントは、SIP 電話機に対して生成されません。これらのコール イベントが予想されるサード パーティのアプリケーションは、SCCP 電話機 を使用する必要があります。
-
CallOpenLogicalChannelEvent
-
CallRingEvent
-
DeviceLampModeChangedEvent
-
DeviceModeChangedEvent
-
DeviceDisplayChangedEvent
-
DeviceFeatureButtonPressedEvent
-
DeviceKeyPressedEvent
-
DeviceLampModeChangedEvent
-
DeviceRingModeChangedEvent