9. 非共有アピアランス UA との相互運用性 (Interoperability with Non-shared Appearance UAs)

共有アピアランスを直接サポートしない基本的な UA が共有アピアランスグループの一部となることを許可することが望ましいです。これをサポートするために、プロキシはアピアランスエージェントと協力する必要があります。これは基本的な共有アピアランスアーキテクチャでは必須ではありません; その結果、非共有アピアランス UA との共有アピアランス相互運用性は、すべての共有アピアランス展開で利用可能ではありません。

まず、ダイアログイベントまたは共有アピアランス機能をサポートしない UA について説明します。次に、ダイアログイベントはサポートするが共有アピアランス機能はサポートしない UA について説明します。

9.1. アピアランスの割り当て (Appearance Assignment)

アピアランスの知識がない UA は、アピアランスエージェントによって割り当てられた場合にのみ、発信呼び出しのアピアランス番号を持ちます。非共有アピアランス UA が Join または Replaces をサポートしない場合、これらのオプションが利用できないことを示すために、すべてのダイアログを "exclusive" (排他的) としてマークすべきです (SHOULD)。これらのダイアログを "exclusive" としてマークすることで、より良いユーザーエクスペリエンスを提供し、余分な SIP メッセージングの失敗を回避します。

9.2. アピアランスの解放 (Appearance Release)

すべての場合において、アピアランスエージェントは、アピアランスをグループに戻すためにダイアログの生存期間を認識している必要があります。

また、任意のダイアログ状態の変更 (保留など) をダイアログイベントパッケージを通じてグループ内の他の UA が利用できるようにすることも望ましいです。アピアランスエージェントが非共有アピアランス対応 UA からのダイアログに対して Record-Route を行うプロキシを含む場合、アピアランスエージェントは保留などを含むダイアログの状態を知ることができます。この情報は、エンドツーエンドで暗号化されていない INVITE および re-INVITE メッセージの検査から判断でき、他の UA に伝達されるダイアログ情報に追加できます。

9.3. ダイアログイベントはサポートするが共有アピアランスはサポートしない UA (UAs Supporting Dialog Events but Not Shared Appearance)

ダイアログイベントはサポートするが共有アピアランス機能はサポートしない UA との相互運用性は、より簡単です。以前と同様に、すべてのアピアランス番号の割り当てはアピアランスエージェントによって行われる必要があります。アピアランスエージェントは、NOTIFY にアピアランス情報を含めるべきです (SHOULD) -- この UA は単にこの追加情報を無視します。このタイプの UA は、アピアランス番号の制限も無視し、排他的とマークされたダイアログに参加または置換しようとする可能性があります。その結果、プロキシまたは UA はそのようなリクエストを拒否する必要があります。そうしないと、ダイアログが参加または取得されます。