メインコンテンツまでスキップ

8. ユーザーインターフェースに関する考慮事項 (User Interface Considerations)

呼び出しに割り当てられたアピアランス番号は、異種のユーザーインターフェースを持つ複数のデバイスで呼び出しを処理しながら、ユーザーが一貫したモデルを見ることができるようにする重要な概念です。アピアランス番号の注意深い取り扱いは、ユーザーの期待に応えるために不可欠です。また、正しい呼び出し/アピアランス状態をユーザーにレンダリングすることも重要です。

8.1. アピアランス番号のレンダリング (Appearance Number Rendering)​

異なる UA は異なるユーザーインターフェース機能を持っているため、一部の UA には他の UA にはない制限があることが一般的です。すべての UA にわたる完全な相互運用性は明らかに不可能ですが、注意深い設計により、各 UA の限界までの相互運用性を達成できます。

以下のガイドラインは、3つの典型的なユーザーインターフェース実装でアピアランス番号をどのように処理すべきかを示唆しています。

8.1.1. 単一アピアランス UA (Single Appearance UAs)​

これらのデバイスは、単一のアピアランスのステータス表示のみを表示する機能に制約されています。UA は依然としてアピアランス番号 "1" で注釈された メッセージを送信すべきです (SHOULD)。番号 "1" 以外のアピアランスの呼び出し表示は、480 (Temporarily Unavailable、一時的に利用不可) または 486 (Busy Here、話し中) レスポンスで拒否されるべきです (SHOULD)。これは、単一アピアランス UA が共有 AOR への自分自身の呼び出しに応答できないことを意味することに注意してください。この呼び出しは2番目のアピアランス番号を使用するためです。

8.1.2. デュアルアピアランス UA (Dual Appearance UAs)​

これらのデバイスは、本質的にキャッチホンを実装する単一アピアランス電話です。これらは、2つのアピアランス間を切り替える (トグルまたはフラッシュフック) ことができ、おそらく他のアピアランスのステータスを示す可聴音を持つ非常にシンプルなユーザーインターフェースを持っています。これらの UA は、アピアランス番号 "1" と "2" のみを使用します。

8.1.3. 固定アピアランス番号を持つ共有アピアランス UA (Shared Appearance UAs with Fixed Appearance Number)​

この UA は典型的な「ビジネスクラス」のハードフォンです。通常、多数のアピアランスが静的に構成され、ボタンにラベル付けされ、これらの構成されたアピアランスを使用して呼び出しを管理できます。この範囲外の呼び出しは拒否されるべきであり、空きボタンにマッピングされるべきではありません。これらのデバイスのユーザーは、発信呼び出しのために特定のアピアランス番号を占有することが多く、UA は呼び出しを続行する前にアピアランス番号を占有し、アピアランスエージェントからの確認を待つ必要があります。

8.1.4. 可変アピアランス番号を持つ共有アピアランス UA (Shared Appearance UAs with Variable Appearance Numbers)​

この UA は通常、ソフトフォンまたはグラフィカルに豊富なユーザーインターフェースのハードフォンです。これらの場合、アピアランスインデックスのアイデアさえ不要に思えるかもしれません。ただし、これらの電話が他の電話タイプと正常に相互運用できるようにするためには、進行中の呼び出しの表示順序を制御するためにアピアランスインデックスを使用することが重要です。順序が一貫しているべきであること以外、プレゼンテーションに関する具体的なガイダンスは示されていません。これらのデバイスは通常、アピアランス番号についてアピアランスエージェントからの確認を待たずに呼び出しを行うことができます。

8.1.5. ユーザーインターフェースの問題例 (Example User Interface Issues)​

各スタイルのユーザーインターフェースが直面する問題は、この例で容易に見ることができます:

  1. 呼び出しが共有アピアランスグループに到着し、アピアランス番号 "1" が割り当てられます。すべての UA は、この呼び出しの到着をユーザーにレンダリングできるはずです。

  2. 別の呼び出しが共有アピアランスグループに到着し、アピアランス番号 "2" が割り当てられます。単一アピアランス UA は、この呼び出しをユーザーに提示すべきではありません。他の UA は、この呼び出しを最初の呼び出しと区別して提示することに問題がないはずです。

  3. 最初の呼び出しがクリアされ、アピアランス番号 "1" が解放されます。単一アピアランス UA は、最初のアピアランス以外の呼び出しを管理できないため、呼び出しがないことを示すべきです。両方の共有アピアランス UA は、アピアランス番号 "1" が現在空いていることを明確に示すべきですが、アピアランス番号 "2" にはまだ呼び出しがあります。

  4. 3番目の呼び出しが到着し、アピアランス番号 "1" が割り当てられます。すべての UA は、この新しい呼び出しの到着をユーザーにレンダリングできるはずです。複数のアピアランス UA は、2番目の呼び出しの存在を示し続けるべきであり、プレゼンテーション順序が呼び出しの到着順序ではなくアピアランス番号に関連していることを確認すべきです。

8.2. 呼び出し状態のレンダリング (Call State Rendering)​

共有アピアランス機能を実装する UA は通常、グループ内の他のアピアランスの状態を提供するユーザーインターフェースを持っています。アピアランスエージェントからのダイアログ状態 NOTIFY が処理されると、この情報をレンダリングできます。最もシンプルなユーザーインターフェースでも通常、アイドル、アクティブ、保留の3つの状態があります。アイドル状態は通常ランプ消灯で示され、アピアランスエージェントによって報告されるように、アピアランス番号がどのダイアログとも関連付けられていない場合に、アピアランスに対して示されます。アクティブ状態は通常ランプ点灯で示され、アピアランスエージェントによって報告されるように、アピアランス番号が少なくとも1つのダイアログと関連付けられていることを意味します。保留状態は、しばしば点滅するランプで示され、共有アピアランスグループ内の UA の観点から呼び出し状態が保留であることを意味します。これは、ローカルターゲット URI に "+sip.rendering=no" 機能タグ [RFC3840] が存在することによって判断できます。リモートターゲット URI の保留状態はこの表示には関係ないことに注意してください。結合されたダイアログの場合、すべてのローカルターゲット URI が "+sip.rendering=no" 機能タグで示されている場合にのみ、状態は保留としてレンダリングされます。

に最終更新