10. Registrations
10 登録 (Registrations)
10.1 概要 (Overview)
SIP は discover 機能を提供します。ユーザーが別のユーザーとのセッションを開始したい場合、SIP は宛先ユーザーに到達可能な現在のホストを発見しなければなりません (MUST)。この discover プロセスは、リクエストを受信し、ユーザーの位置の知識に基づいて送信先を決定し、そこに送信する責任を持つ、proxy server や redirect server などの SIP ネットワーク要素によって頻繁に達成されます。このために、SIP ネットワーク要素は、特定の domain に対する address binding を提供する location service と呼ばれる抽象サービスを参照します。これらの address binding は、着信 SIP または SIPS URI (たとえば sip:[email protected]) を、望ましいユーザーに「より近い」1 つ以上の URI (たとえば sip:[email protected]) にマッピングします。最終的に、proxy は、受信した URI を、目的の受信者が現在存在するユーザーエージェントにマッピングする location service を参照します。
登録は、address-of-record URI を 1 つ以上の contact address に関連付ける、特定の domain の location service 内に binding を作成します。したがって、その domain の proxy が Request-URI が address-of-record に一致するリクエストを受信した場合、proxy はそのリクエストをその address-of-record に登録された contact address に転送します。一般に、その address-of-record へのリクエストがその domain にルーティングされる場合にのみ、domain の location service に address-of-record を登録することには意味があります。ほとんどの場合、これは登録の domain が address-of-record の URI 内の domain と一致する必要があることを意味します。
location service の内容を確立する方法は多数あります。1 つの方法は管理的なものです。上記の例では、Bob は企業データベースへのアクセスを通じて engineering 部門のメンバーであることが知られています。しかし、SIP は UA が binding を明示的に作成するためのメカニズムを提供します。このメカニズムは registration として知られています。
登録には、registrar と呼ばれる特別な種類の UAS への REGISTER リクエストの送信が含まれます。registrar は、domain の location service のフロントエンドとして機能し、REGISTER リクエストの内容に基づいてマッピングを読み書きします。この location service は、その後、通常、その domain のリクエストをルーティングする責任を持つ proxy server によって参照されます。
登録プロセス全体の図を Figure 2 に示します。registrar と proxy server は、ネットワーク内の単一のデバイスによって演じることができる論理的な役割であることに注意してください。明確にするために、この図では 2 つを分離しています。また、UAs は、2 つが別の要素である場合、registrar に到達するために proxy server を通じてリクエストを送信してもかまいません (MAY)。
SIP は、location service を実装するための特定のメカニズムを強制しません。唯一の要件は、一部の domain の registrar が location service へのデータの読み書きができなければならない (MUST) こと、およびその domain の proxy または redirect server が同じデータを読み取ることができなければならない (MUST) ことです。registrar は、同じ domain の特定の SIP proxy server と同一の場所に配置されてもかまいません (MAY)。
10.2 REGISTER リクエストの構築 (Constructing the REGISTER Request)
REGISTER リクエストは、binding の追加、削除、および問い合わせを行います。REGISTER リクエストは、address-of-record と 1 つ以上の contact address との間の新しい binding を追加できます。特定の address-of-record の代わりに、適切に認可された第三者によって登録を実行できます。クライアントはまた、以前の binding を削除したり、address-of-record に対して現在どの binding が配置されているかを問い合わせたりできます。
特記されている場合を除き、REGISTER リクエストの構築および REGISTER リクエストを送信するクライアントの動作は、Section 8.1 および Section 17.1 で説明された一般的な UAC 動作と同一です。
REGISTER リクエストは dialog を確立しません。UAC は、Section 8.1 で説明された事前に存在する route set に基づいて、REGISTER リクエストに Route header field を含めてもかまいません (MAY)。Record-Route header field は、REGISTER リクエストまたはレスポンスには意味がなく、存在する場合は無視されなければなりません (MUST)。特に、UAC は、REGISTER リクエストに対する応答に Record-Route header field の存在または欠如に基づいて、新しい route set を作成してはなりません (MUST NOT)。
次の header field は、Contact を除き、REGISTER リクエストに含まれなければなりません (MUST)。Contact header field は含めてもかまいません (MAY)。
Request-URI: Request-URI は、登録の対象となる location service の domain を指定します (たとえば "sip:chicago.com")。SIP URI の "userinfo" および "@" コンポーネントは存在してはなりません (MUST NOT)。
To: To header field には、作成、問い合わせ、または変更される登録の address-of-record が含まれます。To header field と Request-URI フィールドは通常異なります。なぜなら、前者にはユーザー名が含まれるからです。この address-of-record は SIP URI または SIPS URI でなければなります (MUST)。
From: From header field には、登録に責任を持つ人物の address-of-record が含まれます。値は、リクエストが第三者登録でない限り、To header field と同じです。
Call-ID: 特定の registrar に送信されるすべての登録では、UAC からのすべての登録が同じ Call-ID header field value を使用すべきです (SHOULD)。
同じクライアントが異なる Call-ID 値を使用した場合、registrar は、遅延した REGISTER リクエストが順不同で到着したかどうかを検出できなくなる可能性があります。
CSeq: CSeq value は、REGISTER リクエストの適切な順序付けを保証します。UA は、同じ Call-ID を持つ各 REGISTER リクエストについて、CSeq value を 1 つ増やさなければなりません (MUST)。
Contact: REGISTER リクエストには、address binding を含む 0 個以上の value を持つ Contact header field が含まれてもかまいません (MAY)。
UAs は、registrar から以前のものに対する最終レスポンスを受信するか、以前の REGISTER リクエストがタイムアウトするまで、新しい登録 (つまり、新しい Contact header field value を含むもの。再送ではありません) を送信してはなりません (MUST NOT)。
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| [email protected]
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ [email protected]
carol
Figure 2: REGISTER example
REGISTER リクエストにおいて特別な意味を持つ次の Contact header パラメータがあります。
action: RFC 2543 の "action" パラメータは非推奨となりました。UAC は "action" パラメータを使用すべきではありません (SHOULD NOT)。
expires: "expires" パラメータは、UA が binding を有効にしておきたい期間を示します。値は秒数を示す数値です。このパラメータが提供されない場合は、代わりに Expires header field の値が使用されます。実装は、2**32-1 (4294967295 秒、または 136 年) より大きい値を 2**32-1 と同等として扱ってもかまいません (MAY)。不正な形式の値は 3600 と同等として扱われるべきです (SHOULD)。
10.2.1 binding の追加 (Adding Bindings)
registrar に送信される REGISTER リクエストには、address-of-record に対する SIP リクエストを転送する先となる contact address が含まれます。address-of-record は、REGISTER リクエストの To header field に含まれます。
Request の Contact header field value は、典型的には、特定の SIP endpoint を識別する SIP または SIPS URI (たとえば "sip:[email protected]") で構成されますが、任意の URI scheme を使用してもかまいません (MAY)。たとえば、SIP UA は、電話番号 (tel URL、RFC 2806 [9] を使用) やメールアドレス (mailto URL、RFC 2368 [32] を使用) を address-of-record の Contact として登録することを選択できます。
たとえば、address-of-record が "sip:[email protected]" である Carol は、chicago.com domain の SIP registrar に登録します。彼女の登録は、その後、chicago.com domain の proxy server によって使用され、Carol の address-of-record に対するリクエストを彼女の SIP endpoint にルーティングします。
クライアントが registrar で binding を確立すると、必要に応じて、既存の binding に対する新しい binding または変更を含む後続の登録を送信してもかまいません (MAY)。REGISTER リクエストに対する 2xx レスポンスには、この registrar でのこの address-of-record に対して登録された binding の完全なリストが Contact header field に含まれます。
REGISTER リクエストの To header field 内の address-of-record が SIPS URI である場合、リクエスト内の Contact header field value も SIPS URI であるべきです (SHOULD)。クライアントは、contact address によって表されるリソースのセキュリティが他の手段によって保証されている場合にのみ、SIPS address-of-record の下に非 SIPS URI を登録すべきです (SHOULD)。これは、SIP 以外のプロトコルを呼び出す URI、または TLS 以外のプロトコルによって保護された SIP デバイスに適用される場合があります。
登録はすべての binding を更新する必要はありません。典型的には、UA は自身の contact address のみを更新します。
10.2.1.1 Contact Address の有効期限間隔の設定 (Setting the Expiration Interval of Contact Addresses)
クライアントが REGISTER リクエストを送信する場合、登録を有効にしておきたい期間を示す有効期限間隔を提案してもかまいません (MAY)。(Section 10.3 で説明されているように、registrar はローカルポリシーに基づいて実際の時間間隔を選択します。)
クライアントが binding の提案された有効期限間隔を表現する方法は 2 つあります。Expires header field または "expires" Contact header パラメータを通じてです。後者は、単一の REGISTER リクエストで複数の binding が与えられている場合に per-binding ベースで有効期限間隔を提案することを許可します。一方、前者は "expires" パラメータを含まないすべての Contact header field value に対して有効期限間隔を提案します。
提案された有効期限を表現する両方のメカニズムが REGISTER に存在しない場合、クライアントはサーバーが選択することを望んでいることを示しています。
10.2.1.2 Contact Address 間の優先順位 (Preferences among Contact Addresses)
REGISTER リクエストで複数の Contact が送信される場合、登録する UA は、これらの Contact header field value 内のすべての URI を、To フィールド内の address-of-record に関連付けるつもりです。このリストは、Contact header field の "q" パラメータを使用して優先順位付けできます。"q" パラメータは、この address-of-record の他の binding と比較した、特定の Contact header field value の相対的な優先度を示します。Section 16.6 は、proxy server がこの優先度表示をどのように使用するかを説明しています。
10.2.2 binding の削除 (Removing Bindings)
登録は soft state であり、更新されない限り期限切れになりますが、明示的に削除することもできます。クライアントは、Section 10.2.1 で説明されているように、registrar によって選択された有効期限間隔に影響を与えることを試みることができます。UA は、REGISTER リクエスト内のその contact address に対して "0" の有効期限間隔を指定することにより、binding の即時削除を要求します。binding が有効期限間隔が経過する前に削除できるように、UAs はこのメカニズムをサポートすべきです (SHOULD)。
REGISTER 固有の Contact header field value の "*" はすべての登録に適用されますが、Expires header field が値 "0" と共に存在しない限り使用してはなりません (MUST NOT)。
"*" Contact header field value を使用すると、登録する UA は、その正確な値を知らなくても、address-of-record に関連付けられたすべての binding を削除できます。
10.2.3 binding の取得 (Fetching Bindings)
任意の REGISTER リクエストに対する成功レスポンスには、リクエストに Contact header field が含まれていたかどうかに関わらず、既存の binding の完全なリストが含まれます。REGISTER リクエストに Contact header field が存在しない場合、binding のリストは変更されません。
10.2.4 binding の更新 (Refreshing Bindings)
各 UA は、以前に確立した binding を更新する責任があります。UA は、他の UA によって設定された binding を更新すべきではありません (SHOULD NOT)。
registrar からの 200 (OK) レスポンスには、すべての現在の binding を列挙する Contact フィールドのリストが含まれます。UA は、Section 19.1.4 の比較規則を使用して、各 contact address を調べ、それが contact address を作成したかどうかを確認します。そうである場合、expires パラメータ、または存在しない場合は Expires フィールドの値に従って有効期限間隔を更新します。その後、UA は、有効期限間隔が経過する前に、各 binding に対して REGISTER リクエストを発行します。いくつかの更新を 1 つの REGISTER リクエストに結合してもかまいません (MAY)。
UA は、単一のブートサイクル中のすべての登録に同じ Call-ID を使用すべきです (SHOULD)。登録の更新は、リダイレクトされない限り、元の登録と同じネットワークアドレスに送信されるべきです (SHOULD)。
10.2.5 内部クロックの設定 (Setting the Internal Clock)
REGISTER リクエストに対するレスポンスに Date header field が含まれている場合、クライアントは、任意の内部クロックを設定するために現在時刻を学習するために、この header field を使用してもかまいません (MAY)。
10.2.6 registrar の発見 (Discovering a Registrar)
UAs は、登録を送信するアドレスを決定するために 3 つの方法を使用できます。設定による方法、address-of-record の使用、および multicast です。UA は、この仕様の範囲外の方法で、registrar アドレスを設定できます。設定された registrar アドレスがない場合、UA は address-of-record の host 部分を Request-URI として使用し、通常の SIP サーバー位置メカニズム [4] を使用して、そこにリクエストを宛先指定すべきです (SHOULD)。たとえば、ユーザー "sip:[email protected]" の UA は、REGISTER リクエストを "sip:chicago.com" に宛先指定します。
最後に、UA は multicast を使用するように設定されてもかまいません (MAY)。multicast 登録は、よく知られた "all SIP servers" multicast アドレス "sip.mcast.net" (IPv4 の場合は 224.0.1.75) に宛先指定されます。よく知られた IPv6 multicast アドレスは割り当てられていません。そのような割り当ては、必要に応じて別途文書化されます。SIP UAs はそのアドレスをリッスンし、それを使用して他のローカルユーザーの場所を認識するようになっていてもかまいません (MAY) ([33] を参照)。ただし、それらはリクエストに応答しません。
multicast 登録は、複数の企業が同じローカルエリアネットワークを共有している場合など、一部の環境では不適切な場合があります。
10.2.7 リクエストの送信 (Transmitting a Request)
REGISTER メソッドが構築され、メッセージの宛先が識別されると、UAC は REGISTER をトランザクション層に引き渡すために、Section 8.1.2 で説明された手順に従います。
REGISTER が応答を生成しなかったためにトランザクション層がタイムアウトエラーを返した場合、UAC は同じ registrar への登録を直ちに再試行すべきではありません (SHOULD NOT)。
直ちに再試行しても、タイムアウトする可能性が高いです。タイムアウトの原因となる状況が修正されるのを合理的な時間間隔待つことは、ネットワーク上の不要な負荷を削減します。特定の間隔は強制されません。
10.2.8 エラーレスポンス (Error Responses)
UA が 423 (Interval Too Brief) レスポンスを受信した場合、REGISTER リクエスト内のすべての contact address の有効期限間隔を、423 (Interval Too Brief) レスポンスの Min-Expires header field 内の有効期限間隔以上に等しくした後に、登録を再試行してもかまいません (MAY)。
10.3 REGISTER リクエストの処理 (Processing REGISTER Requests)
registrar は、REGISTER リクエストに応答し、その管理 domain 内の proxy server および redirect server からアクセス可能な binding のリストを維持する UAS です。registrar は、Section 8.2 および Section 17.2 に従ってリクエストを処理しますが、REGISTER リクエストのみを受け入れます。registrar は 6xx レスポンスを生成してはなりません (MUST NOT)。
registrar は、必要に応じて REGISTER リクエストをリダイレクトしてもかまいません (MAY)。1 つの一般的な使用法は、multicast インターフェースでリッスンしている registrar が、302 (Moved Temporarily) レスポンスで multicast REGISTER リクエストを自身の unicast インターフェースにリダイレクトする場合です。
registrar は、REGISTER リクエストに Record-Route header field が含まれている場合、それを無視しなければなります (MUST)。registrar は、REGISTER リクエストに対するいかなるレスポンスにも Record-Route header field を含めてはなりません (MUST NOT)。
registrar は、REGISTER を未知のリクエストとして扱い、Record-Route header field value を追加した proxy を通過したリクエストを受信する可能性があります。
registrar は、(たとえば設定を通じて) それが binding を維持する domain の集合を知っている必要があります。REGISTER リクエストは、受信された順序で registrar によって処理されなければなります (MUST)。REGISTER リクエストはまた、アトミックに処理されなければなります (MUST)。つまり、特定の REGISTER リクエストは完全に処理されるか、まったく処理されないかのいずれかであることを意味します。各 REGISTER メッセージは、他の登録や binding 変更とは独立して処理されなければなります (MUST)。
REGISTER リクエストを受信すると、registrar は以下の手順に従います。
1. registrar は Request-URI を検査し、Request-URI で識別された domain の binding へのアクセス権があるかどうかを判断します。ない場合、およびサーバーが proxy server としても機能する場合、サーバーは Section 16 で説明されたメッセージの proxy 処理の一般的な動作に従って、宛先 domain にリクエストを転送すべきです (SHOULD)。
2. registrar が必要な拡張をサポートしていることを保証するために、registrar は Section 8.2.2 で UAS 向けに説明された Require header field value を処理しなければなります (MUST)。
3. registrar は UAC を認証すべきです (SHOULD)。SIP ユーザーエージェントの認証メカニズムは Section 22 で説明されています。登録動作は、SIP の一般的な認証フレームワークをいかなる形でも上書きしません。認証メカニズムが利用できない場合、registrar は From アドレスをリクエストの発信者の表明されたアイデンティティとして取得してもかまいません (MAY)。
4. registrar は、認証されたユーザーがこの address-of-record の登録を変更することを許可されているかどうかを判断すべきです (SHOULD)。たとえば、registrar は、ユーザー名を、そのユーザーが binding を変更する権限を持つ address-of-record のリストにマッピングする認可データベースを参照する場合があります。認証されたユーザーが binding を変更することを許可されていない場合、registrar は 403 (Forbidden) を返し、残りの手順をスキップしなければなります (MUST)。
第三者登録をサポートするアーキテクチャでは、1 つのエンティティが複数の address-of-record に関連付けられた登録の更新に責任を持つ場合があります。
5. registrar は、リクエストの To header field から address-of-record を抽出します。address-of-record が Request-URI の domain に対して無効な場合、registrar は 404 (Not Found) レスポンスを送信し、残りの手順をスキップしなければなります (MUST)。その後、URI は正規形に変換されなければなります (MUST)。そのためには、すべての URI パラメータ (user-param を含む) を削除し、エスケープされた文字はすべてエスケープされていない形に変換されなければなります (MUST)。結果は binding のリストへのインデックスとして機能します。
6. registrar は、リクエストに Contact header field が含まれているかどうかを確認します。含まれていない場合は、最後の手順にスキップします。Contact header field が存在する場合、registrar は、特別な値 "*" および Expires フィールドを含む 1 つの Contact フィールド value があるかどうかを確認します。リクエストに追加の Contact フィールドまたはゼロ以外の有効期限がある場合、リクエストは無効であり、サーバーは 400 (Invalid Request) を返し、残りの手順をスキップしなければなります (MUST)。そうでない場合、registrar は Call-ID が各 binding に格納された値と一致するかどうかを確認します。一致しない場合は、binding を削除しなければなりません (MUST)。一致する場合は、リクエスト内の CSeq がその binding に格納された値よりも高い場合にのみ binding を削除しなければなりません (MUST)。そうでない場合、更新は中止されなければならず (MUST)、リクエストは失敗します。
7. registrar は、Contact header field 内の各 contact address を順番に処理します。各アドレスについて、次のように有効期限間隔を決定します。
- フィールド value に "expires" パラメータがある場合、その値を要求された有効期限として採用しなければなります (MUST)。
- そのようなパラメータがないが、リクエストに Expires header field がある場合、その値を要求された有効期限として採用しなければなります (MUST)。
- どちらもない場合、ローカルに設定されたデフォルト値を要求された有効期限として採用しなければなります (MUST)。
registrar は、要求された有効期限間隔よりも短い有効期限を選択してもかまいません (MAY)。要求された有効期限間隔がゼロより大きく、かつ 1 時間未満であり、かつ registrar 設定の最小値より小さい場合にのみ、registrar は 423 (Interval Too Brief) レスポンスで登録を拒否してもかまいません (MAY)。このレスポンスには、registrar が受け入れる意思のある最小の有効期限間隔を示す Min-Expires header field が含まれなければなります (MUST)。その後、残りの手順をスキップします。
registrar が登録間隔を設定できるようにすることで、過度に頻繁な登録更新から保護され、維持する必要のある状態が制限され、登録が古くなる可能性が減少します。登録の有効期限間隔は、サービスの作成で頻繁に使用されます。例としては、ユーザーが短時間しか端末で利用できない場合がある follow-me サービスがあります。したがって、registrar は短い登録を受け入れるべきです (SHOULD)。間隔が短すぎて更新が registrar のパフォーマンスを低下させる場合にのみ、リクエストを拒否する必要があります。
各アドレスについて、registrar は URI 比較規則を使用して、現在の binding のリストを検索します。binding が存在しない場合、仮に追加されます。binding が存在する場合、registrar は Call-ID value を確認します。既存の binding の Call-ID value がリクエストの Call-ID value と異なる場合、有効期限がゼロであれば binding は削除されなければならず (MUST)、そうでなければ更新されなければなりません (MUST)。それらが同じである場合、registrar は CSeq value を比較します。value が既存の binding よりも高い場合、上記のように binding を更新または削除しなければなります (MUST)。そうでない場合、更新は中止されなければならず (MUST)、リクエストは失敗します。
このアルゴリズムは、同じ UA からの順不同のリクエストが無視されることを保証します。
各 binding レコードは、リクエストから Call-ID および CSeq value を記録します。
binding 更新および追加のすべてが成功した場合にのみ、binding 更新がコミット (つまり、proxy または redirect server に可視化) されなければなります (MUST)。それらのいずれか 1 つが失敗した場合 (たとえば、バックエンドデータベースのコミットが失敗したため)、リクエストは 500 (Server Error) レスポンスで失敗しなければならず (MUST)、すべての暫定的な binding 更新が削除されなければなります (MUST)。
8. registrar は 200 (OK) レスポンスを返します。レスポンスには、すべての現在の binding を列挙する Contact header field value が含まれなければなります (MUST)。各 Contact value には、registrar によって選択された有効期限間隔を示す "expires" パラメータが含まれなければなります (MUST)。レスポンスには Date header field が含まれるべきです (SHOULD)。