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

5. 規範的記述

このセクションは、共有アピアランス機能拡張を規範的に記述します。この文書全体で以下の定義が使用されます:

Appearance number (アピアランス番号): アピアランス番号は、AORの1つ以上のダイアログに関連付けられた正の整数です。アピアランス番号はAppearance Agentによって管理され、この仕様をサポートするUAによってユーザーに表示およびレンダリングされます。

Seizing (占有): アピアランスは、コールが発信される前に占有することで予約できます。アピアランスは、実際にダイアログを開始する前に「trying」の人工的な状態を通信することで占有できます。

Selecting (選択) (または Not-Seizing): ダイアログを開始する前に「trying」の人工的な状態の通信がない場合、アピアランスは単に選択されます（すなわち、占有されません）。

5.1. 要素​

この機能を実装する完全なシステムは以下で構成されます:

  1. SIPダイアログイベントパッケージおよび共有アピアランスダイアログパッケージ拡張と動作のパブリケーション、サブスクリプション、通知をサポートするUA。

  2. Event State Compositor (ESC)および共有アピアランスダイアログパッケージ拡張と動作を実装するダイアログイベントパッケージのState Agentで構成されるAppearance Agent。

  3. State Agentと通信できるフォーキングプロキシサーバー。

  4. 登録イベントパッケージをサポートするレジストラ。

これらの要素の動作は、ダイアログパッケージ拡張の定義の後の以下のセクションで規範的に記述されます。

5.2. 共有アピアランスダイアログパッケージ拡張​

本仕様は, SIP ダイアログイベントパッケージ [RFC4235] の拡張として 4 つの新しい要素を定義します。スキーマは第 6 節で定義されています。要素は <appearance>, <exclusive>, <joined-dialog>, <replaced-dialog> で, これらは <dialog> 要素のサブ要素です。

5.2.1. <appearance> 要素​

<appearance> 要素は <dialog> 要素の子であり, 親 <dialog> 要素によって記述されるダイアログの外観番号を伝えるために使用されます。UA が, 親 <dialog> の state 属性が "trying" である PUBLISH でこの要素を外観エージェントに送信する場合, UA は指定されたダイアログ識別子を持つ現在または将来のダイアログに指定された外観番号を割り当てることを要求しています。外観エージェントが NOTIFY で <appearance> 要素を送信する場合, その外観番号が指定されたダイアログに割り当てられたことを示します。

なお, <dialog-info> 要素は, それを含む要求が UA と外観エージェントのどちらから送信されたかに関わらず, UA ("entity" 属性で命名される) の視点から含まれるダイアログを記述します。特に, UA が記述されたダイアログ内で要求を送信した場合, To ヘッダーフィールド URI は <remote> <identity> 値と一致し, to-tag パラメータは remote-tag 属性と一致します。同様に, From ヘッダーフィールド URI は <local> <identity> 値と一致し, from-tag パラメータは local-tag 属性と一致します。

5.2.2. <exclusive> 要素​

<exclusive> 要素は <dialog> 要素の子であり, ブール値です。true の場合, UA が, <exclusive> 要素の親である <dialog> 要素によって記述されるダイアログを対象とする Join または Replaces ヘッダーフィールド付きの INVITE を受け入れる意思がないことを示します。たとえば, 一部の共有アピアランスシステムでは, コールが保留中の場合にのみコールのピックアップを許可します。この場合, 保留状態によって暗黙に示される "exclusive" 値ではなく, コールが保留中は <exclusive> 要素を "false" に, 保留中でない場合は "true" に設定するべきです。

この要素はあくまでヒントであることに注意することが重要です。他の UA がコールを引き継いだり参加したりするのを防ぐために, UA は <exclusive> タグを設定することに加えて, 完全なダイアログ情報を外観エージェントに報告しないこともできます。完全なダイアログ情報 (Call-ID, remote-tag, local-tag) がないと, 他の UA は Join または Replaces ヘッダーフィールドを構築できません。UA は <exclusive> を "true" に設定しても, このダイアログに関連する INVITE Join を拒否できる準備ができていなければなりません。これらのダイアログ識別子がすでに外観エージェントと共有されている場合, UA はそれらを変更するために INVITE Replaces を送信し, 新しいものを外観エージェントに報告しないことができます。

プロキシがどのダイアログが排他的とマークされているかを知っている場合, プロキシはそれらのダイアログ識別子を含む INVITE Join および INVITE Replaces 要求を 403 (Forbidden) 応答で拒否することでこの排他性を強制してもよい (MAY) です。

なお, 排他性は外観番号の選択や占有とは無関係です -- むしろ, ダイアログに対して実行できるコール制御操作に関するものです。

<exclusive> 要素が存在しない場合, false とみなされます。

5.2.3. <joined-dialog> 要素​

<joined-dialog> 要素は <dialog> 要素の子であり, そのダイアログと結合 (ミキシングまたはブリッジ) されている他のダイアログのダイアログ識別子を伝えるために使用されます。ミキシングされたダイアログの共通エンドポイントである (したがってミキシング操作を制御する) UA のみが, 外観エージェントへのパブリケーションにこの要素を含めるべきです。なお, ダイアログの結合に Join ヘッダーフィールドが使用されなかった場合でも, この要素は使用されるべきです。たとえば, UA 上の 2 つの別々のダイアログは, SIP コール制御操作なしで結合できます。結合されたダイアログは同じ外観番号を共有します。

<joined-dialog> 要素が存在しない場合, そのダイアログは他のダイアログと結合されておらず, 結合される予定もないと見なされます。

5.2.4. <replaced-dialog> 要素​

<replaced-dialog> 要素は <dialog> 要素の子であり, このダイアログによって置換される, または置換された他のダイアログのダイアログ識別子を伝えるために使用されます。たとえば, グループ内の UA が Replaces 付きの INVITE を送信して別の UA のコールをピックアップする場合, 置換するダイアログに対してこの要素を含めます。置換されたダイアログは同じ外観番号を共有します。

<replaced-dialog> 要素が存在しない場合, そのダイアログは他のダイアログを置換しておらず, 置換する予定もないと見なされます。

5.3. 共有アピアランスユーザーエージェント​

共有外観機能をサポートする UA は, ダイアログ状態パッケージ [RFC4235] と共有外観拡張および第 13 節で定義されている 'shared' Event ヘッダーフィールドパラメータを使用します。

UA は, 第 5.2 節のダイアログパッケージ拡張を SUBSCRIBE [RFC6665], NOTIFY [RFC6665], PUBLISH [RFC3903] とともに使用します。ダイアログイベントパッケージの SUBSCRIBE, NOTIFY, PUBLISH リクエストには, 本仕様で要求される 'shared' Event ヘッダーフィールドパラメータが含まれます。

'shared' Event ヘッダーフィールドパラメータの存在は, UA が本仕様をサポートしていることを外観エージェントに伝えます。

初期化時, UA は AOR のダイアログイベントパッケージをサブスクライブし, SIP イベントフレームワーク [RFC6665] に従ってサブスクリプションを更新しなければなりません。SUBSCRIBE リクエストが失敗した場合, 外観エージェントが存在しない可能性があり, この AOR に対してこの機能はアクティブではありません。UA は, 条件が変更されたかどうかを確認するために, 4 時間以上の間隔でサブスクリプションを定期的に再試行してもよいです。

4 時間が選ばれたのは, サブスクリプションテストを UA あたり 1 日 6 回に制限するためです。この間隔を増やすと, この失敗トラフィックは減少しますが, 新しくアクティブ化された外観エージェントを発見するのに時間がかかります。

UA は, NOTIFY 内の 'shared' Event ヘッダーフィールドパラメータの存在を使用して, AOR の外観エージェントの存在を発見することもできます。

共有外観機能, コールピックアップ, 結合, ブリッジを実装する UA は, Replaces [RFC3891] または Join [RFC3911] を含む INVITE の送信をサポートしなければなりません。ユーザーエージェントクライアント (UAC) は, RFC 3891 および 3911 のルールに従ってユーザーエージェントサーバー (UAS) によって正しいダイアログが一致するように, Replaces または Join ヘッダーに to-tag および from-tag 情報を含める必要があります。

共有外観機能を実装し INVITE をサポートするすべての UA は, Replaces [RFC3891] または Join [RFC3911] ヘッダーフィールドを含む INVITE の受信をサポートしなければなりません。

ダイアログパッケージ情報を公開または通知する場合, UA は公開時に利用可能な最大のダイアログ識別セットを含めます。ただし, UA が他の UA による呼び出しへの参加またはピックアップを防止したい場合は, 情報を省略してもよいです。ダイアログ識別には, ローカルおよびリモートターゲット URI, call-id, to-tag, from-tag が含まれます。このダイアログ識別情報は [RFC4235] ではオプションですが, 共有外観機能では必須であり, 呼び出し制御操作を可能にします。呼び出しを保留にする場合, ダイアログパッケージ通知でこれを示すために "+sip.rendering=no" 機能タグを使用します。代わりに完全な SDP セッション記述を使用すると, エンドポイントが多くの余分な解析を行う必要があり, コードを不必要に複雑にし, エラーを招きます。

グループ内の他の UA のアイドル/アクティブ/アラート/保留状態を正確にレンダリングすることは, 共有外観機能の重要な部分です。

特定の外観番号を占有する必要がない (または気にしない) UA は, アウトバウンド呼び出しを行うために通常どおり INVITE を送信します。

呼び出しが緊急呼び出しである場合, UA は INVITE を送信する前に確認された占有を待ってはなりません。代わりに, 緊急呼び出しは PUBLISH トランザクションを待たずに進行しなければなりません。

UA が特定の外観番号を必要とする場合, UA はダイアログパッケージ PUBLISH リクエストを送信し, INVITE を送信する前に 2xx 応答を待たなければなりません。これは次の状況で必要です:

  1. ユーザーが発信呼び出しのために特定の外観番号を占有する場合 (たとえば, UA のユーザーインターフェースがこのメタファーを使用している場合, 外観を占有して「オフフック」にする)。

  2. ユーザーが発信呼び出しに外観番号を使用しないことを要求した場合 (すなわち, コンサルテーション呼び出し中, 保留音楽 [RFC7088] などの「サービスメディア」呼び出しの場合, または共有外観グループの一部とは見なされない呼び出しの場合)。

  3. ユーザーが既存の呼び出しに参加 (またはブリッジ) することを選択した場合。

  4. ユーザーが既存の呼び出しを置き換え (または取得) することを選択した場合。

ダイアログの確立前に UA が外観を占有する場合 (上記リストの 1 と 2), すべてのダイアログ情報が利用可能であるとは限らないことに注意してください。特に, UA が宛先 URI を知る前に外観を占有しようとする試みを公開する場合, 最小限またはダイアログ情報が利用できない可能性があります。たとえば, 場合によっては, 呼び出しのローカルターゲット URI のみが既知です: ダイアログ情報はありません。From タグと Call-ID が最初の PUBLISH に存在しなかった場合, この情報が利用可能になり次第, 新しい PUBLISH を送信しなければなりません。

最初の公開により, 外観エージェントはこの UA の外観番号を予約します。公開にダイアログ識別子 (Call-ID または local-tag など) がない場合, 外観エージェントは, いくつかのダイアログ識別子を含む 2 番目の公開まで, UA の特定のダイアログに外観番号を割り当てることができません。

この公開状態は, 早期ダイアログ状態中に [RFC3903] で説明されているように更新されます。そうしないと, 外観エージェントが外観番号を再割り当てする可能性があります。ダイアログが確認状態に移行すると, 公開更新は不要です。

本仕様は, 外観エージェントが UA 公開以外に UA ダイアログの状態について学習する他の手段を持つことを想定しています。本仕様では, PUBLISH は望ましいおよび意図された外観番号操作を示すために使用されます。ダイアログが早期から確認に移行すると, この役割は終了します。したがって, 公開更新は必要ありません。

外観番号は, AOR に関連するアクティブおよび保留中のダイアログの省略ラベルです。この拡張を使用して構築された多くの機能とサービスは, この情報を人間のユーザーに正しくレンダリングすることに依存しています。さらに, この機能のグループの性質は, 異なるベンダーと異なるモデル間でレンダリングが類似している必要があることを意味します。そうしないと, これらのプロトコル拡張の価値と有用性が大幅に低下します。この機能のために正しく設計されたユーザーインターフェースでは, アクティブおよび保留中の各ダイアログの外観番号は, 明示的に (すなわち, 外観番号によって) または暗黙的に (番号付けと順序をユーザーに明確にするユーザーインターフェースメタファーを使用して) ユーザーにレンダリングされます。各ダイアログの遠端 ID (リモートパーティ ID など) は, 外観番号の有用な代替品ではありません。各外観の状態もレンダリングされます (アイドル, アクティブ, ビジー, 結合など)。UA は, 他の SIP ダイアログ識別子を含む 1 つ以上の <joined-dialog> 要素の存在によって, ダイアログのセットが結合 (ブリッジまたはミックス) されていることを知ることができます。ダイアログの外観番号は, 外観エージェントからの <appearance> 要素を含むダイアログパッケージ通知, または着信 INVITE の 'appearance' Alert-Info パラメータから学習できます。それらが競合する場合, ダイアログパッケージ通知が優先されます。

ユーザーは外観番号を選択してから呼び出しを放棄する (オンフックに戻る) 場合があります。この場合, UA は [RFC3903] で説明されているように PUBLISH でイベント状態を削除することにより, 外観番号を解放します。これを行わないと, 外観エージェントによる不要な操作が必要になり, 共有外観グループ内の他の UA が使用できる外観番号を占有します。

UA は, 着信呼び出しに応答する可能性が高い場合にのみ AOR に対して登録すべきです。UA が主に共有外観グループ呼び出しのステータスを監視し, 呼び出しをピックアップまたは結合する場合, UA は AOR に対して登録するのではなく, AOR をサブスクライブするだけにすべきです。監視 UA がサブスクライブするだけでなく登録すると, 大量の不要なネットワークトラフィックが生成されます。

サブスクライブされたすべての UA は, 着信 INVITE の試行状態のダイアログパッケージ NOTIFY を受信します。

UA は, INVITE またはその他のリクエストの Alert-Info ヘッダーフィールドに 'appearance' パラメータを挿入してはなりません。

外観エージェントのみがこれを行う責任があります。

5.3.1. アピアランス番号とコールコンテキスト​

UA の 2 つの個別のダイアログがミックスされていないが, 同じ「コンテキスト」を共有する場合があります。つまり, それらは互いに関連しており, グループ内の他の 2 つのダイアログと同じように扱うべきではありません。この例の 1 つは「コンサルテーションコール」です。ユーザーは既存のダイアログを保留にし, 別のユーザーを呼び出してから, 元のダイアログに切り替えます。以下に説明する別のケースは, 転送操作中に発生します。一時的な期間, UA は他の 2 つの UA とのダイアログに関与しますが, ダイアログは関連しており, 独立したダイアログとして扱うべきではありません。これらのケースは, 新しく作成されたダイアログが既存のダイアログとコンテキストを共有する場合, 外観番号を割り当てないことで最もよく処理されます。ただし, 既存のダイアログが終了した場合, その外観番号は新しく作成されたダイアログに再割り当てする必要があります。

呼び出しを行いたいが外観番号が割り当てられていない UA は, INVITE を送信する前に PUBLISH を送信します。PUBLISH には 'appearance' 要素は存在しませんが, 'shared' Event ヘッダーフィールドパラメータは存在します。外観エージェントポリシーが割り当てられた外観番号のない呼び出しを許可しない場合, 外観エージェントによって 400 (Bad Request) 応答が送信され, UA は外観番号を選択/占有して再公開するか, 公開せずに INVITE を送信します。この場合, 外観エージェントが 1 つを割り当てます。

外観エージェントが外観番号のない呼び出しを拒否すると, コンサルテーションコール, 転送, 保留音楽などの特定の操作が悪影響を受ける可能性があることに注意してください。

5.3.2. アピアランス番号とコール制御​

呼び出しをブリッジまたは取得しようとする INVITE が生成される場合 (つまり, 共有外観グループ内の別のダイアログのダイアログ識別子を持つ Join または Replaces を含む), UA はまず外観エージェントに PUBLISH を送信しなければなりません。この PUBLISH には次のものが含まれます:

  1. <appearance> 要素内の結合または置換された呼び出しの外観番号

  2. ダイアログが結合されている場合, <joined-dialog> 要素内の Join ヘッダーフィールドからのダイアログ情報

  3. ダイアログが置換されている場合, <replaced-dialog> 要素内の Replaces ヘッダーフィールドからのダイアログ情報

この情報は, 外観エージェントが適切な外観割り当て動作を提供できるように提供されることに注意してください。INVITE Join または Replaces が最初に公開せずに送信された場合, 外観エージェントはこの INVITE に新しい外観番号を割り当てる可能性があり, これは間違いです。Join の場合, 公開には <joined-dialog> 要素があり, 外観番号の再利用により外観エージェントが 400 (Bad Request) 応答を生成するのを防ぎます。Replaces の場合, <replaced-dialog> の目的は, BYE が置換ダイアログに残るべきときに外観番号が解放される可能性がある競合状態を防ぐことです。

5.3.3. アピアランス番号と転送​

転送操作中, 操作中に外観番号が変更されないことが重要です。共有外観グループのメンバーである Alice が, 共有外観グループの外にいる Carol と話している例を考えてみましょう。Carol は Alice を, 同じく共有外観グループの外にいる David に転送します。たとえば, Alice が Carol とのセッションに外観 3 を使用している場合, David との結果のセッションも外観番号 3 を使用する必要があります。そうしないと, 外観番号の変更により UI で「ジャンプ」が発生し, ユーザーが混乱する可能性があります。RFC 5589 の用語を使用すると, 2 つの可能なシナリオがあります: Alice は任意のタイプの転送における被転送者 (REFER を受信) または参加転送における転送ターゲット (Replaces を含む INVITE を受信) です。

Alice が被転送者である場合, REFER からトリガーされた INVITE はコンサルテーションコールとして扱われます。Alice は, 外観エージェントがこの INVITE に外観番号を割り当てないように要求して公開すべきです。転送が完了したら, Alice は Carol とのダイアログから David とのダイアログに外観番号を移動するために再度公開すべきです。外観番号を移動するために PUBLISH が送信される場合, 外観エージェントが BYE を見た後に外観番号を再割り当てする競合状態を避けるために, Carol に BYE を送信する前に公開を送信しなければなりません。

Alice がターゲットである場合, 着信 INVITE には Replaces ヘッダーフィールドが含まれます。その結果, 外観エージェントは Carol とのダイアログの外観番号を再利用し, Carol とのダイアログが終了した後もこの外観番号が引き続き使用されます。

5.4. アピアランスエージェント​

本仕様で定義される外観エージェントは, AOR に対して登録された UA のダイアログパッケージ状態エージェントを実装しなければなりません。外観エージェントは, 第 5.2 節で定義された外観ダイアログパッケージ拡張をサポートし, 'shared' Event ヘッダーフィールドパラメータを使用しなければなりません。外観エージェントは, このイベントパッケージのパブリケーションとサブスクリプションをサポートしなければなりません。

外観エージェントは, AOR に関連付けられたすべてのダイアログの状態を発見する方法を持たなければなりません。この情報がコールステートフルプロキシまたはバックツーバックユーザーエージェント (B2BUA) から得られない場合, 外観エージェントは登録イベントパッケージ [RFC3680] を使用して AOR に関連付けられた UA を把握し, それらのダイアログイベント状態をサブスクライブできます。外観エージェントは, 状態を再構築するために UA のダイアログイベント状態をサブスクライブすることもできます。その結果, レジストラは登録イベントパッケージをサポートしなければなりません。

ダイアログパッケージ通知は, RFC 4235 によって "状態または参加情報が変化したダイアログの情報のみを含む" ことが推奨されています。本仕様は次のように RFC 4235 を拡張します。AOR グループ内の UA に以下のイベントが発生するたびに, 外観エージェントはダイアログイベント状態通知を送信すべきです。

  1. コールが受信, 発信, 応答, または終了される。

  2. コールが保留または保留解除される。

  3. コールが結合または置換される。

  4. 外観番号が予約または解放される。

外観エージェントは, すべての着信コールに外観番号を割り当て, 共有グループ AOR にサブスクライブしている UA に即座に通知を送信しなければなりません。Join または Replaces ヘッダーフィールドを持つ着信 INVITE を除き, 新しい外観番号が割り当てられます。この場合, 外観番号は結合または置換されるダイアログの外観番号と一致するべきです。INVITE の Replaces または Join が共有アピアランスグループの外部から来た場合, 外観エージェントは, Replaces または Joined ヘッダーフィールドからのダイアログ情報を含む <joined-dialog> または <replaced-dialog> 要素を NOTIFY に含めます。

外観エージェントは, 着信コールを把握するため, また外観番号をプロキシに渡すか, 適切な外観番号を持つ Alert-Info ヘッダーフィールドが INVITE に含まれるようにするために, フォーキングプロキシと通信できなければなりません。

なお, UA は外観番号が割り当てられていない着信 INVITE を処理できる必要があります。これは外観エージェントの障害やその他のエラー状態によって発生する可能性があります。INVITE を適切にレンダリングできない場合もありますが, これは INVITE を無視したり失敗させたりするよりも良いことです。

外観エージェントは, 特定の外観番号を選択/占有する PUBLISH を受信していない場合, 発信ダイアログに外観番号を割り当てるべきです。

なお, 共有アピアランスグループに外観を認識しない UA が発信する場合でも, 外観エージェントはそれらの UA が送信する INVITE に外観番号を割り当てます。

外観番号付きの PUBLISH を受信した外観エージェントは, そのパブリケーションが有効であることを確認します。ダイアログが置換または結合される/されたことを示す <joined-dialog> または <replaced-dialog> 要素がない限り, 外観番号は 1 つのダイアログにのみ割り当てることができます。選択された外観番号が無効な場合, 400 (Bad Request) 応答が返され, 完全なダイアログイベント状態を含む即時の NOTIFY を UA に送信すべきです。

外観番号なしで, ただし 'shared' Event ヘッダーフィールドパラメータが存在する PUBLISH を受信した外観エージェントは, これを UA が外観番号を割り当てないことを要求していると解釈します。外観エージェントのポリシーがこれを許可しない場合, 400 (Bad Request) 応答が返されます。ポリシーが許可する場合, 200 (OK) 応答が返され, 外観番号は割り当てられません。このダイアログ情報は他の UA によってレンダリングされないため, 外観エージェントはこのダイアログ情報をグループ内の他の UA と共有する (つまり NOTIFY を送信する) 必要はありません。

外観エージェントは, PUBLISH によって外観が要求された時点または INVITE の受信時点から, その外観に関連付けられた最後のダイアログが終了する時点まで, 結合または置換されたすべてのダイアログを含めて, ダイアログに外観番号を割り当てます。早期ダイアログ状態の間, 外観エージェントは PUBLISH 要求への 200 (OK) 応答の Expires ヘッダーフィールドを使用してダイアログ状態パブリケーションのレートを制御します。3 分の間隔が推奨されます (RECOMMENDED)。パブリケーションに関連付けられたダイアログが確認された後は, パブリケーション状態の満了は外観の割り当てに影響しません。パブリケーションにダイアログ状態情報が含まれていない場合, 外観エージェントは UA のために外観番号を予約しなければなりませんが, その外観を UA の特定のダイアログに割り当てることはできません。パブリケーション状態が何らかのダイアログ情報で更新されると, 外観番号を特定のダイアログに割り当てることができます。PUBLISH を使用して外観番号を割り当てられた UA は, [RFC3903] に記載されているように PUBLISH でイベント状態を削除することにより, 外観番号を解放してもよい (MAY) です。

グループのメンバーが共有 AOR に INVITE を送信する場合 (つまり自分たちの AOR を呼び出す場合), 外観エージェントは 2 つの外観番号を割り当てなければなりません。1 つ目の外観番号は, 発信 INVITE に選択または割り当てられたものになります。2 つ目の外観番号は, その INVITE がグループのメンバーにフォークされて戻されるときに外観エージェントが割り当てる別の番号になります。

これは, レガシーシステムにおける共通の動作を保つためのものです。

グループのメンバーが共有 AOR を使用して INVITE を送信する場合, または共有 AOR に送信された INVITE に対して利用可能な外観番号がない場合, プロキシは 403 (Forbidden) 応答コードでその INVITE を拒否してもよい (MAY) です。

外観番号は, グループ AOR に関連付けられた 1 つ以上の UA が参加者であるダイアログにのみ使用されます。グループ AOR への着信 INVITE が別の AOR に転送された場合, 外観番号は直ちに解放され, 別のダイアログに割り当てることができます。