Network Working Group R. Mahy
Request for Comments: 3911 Airespace
Category: Standards Track D. Petrie
Pingtel
October 2004
The Session Initiation Protocol (SIP) "Join" Header
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative.
この文書では、SIPマルチパーティのアプリケーションおよびコール制御で使用する新しいヘッダーを定義します。参加ヘッダは、論理的に新しいSIPダイアログで、既存のSIPダイアログを結合するために使用されます。このプリミティブは、たとえば、さまざまな機能を有効にするために使用することができます：「割り込みイン」、「メッセージスクリーニング」と「コールセンターのモニタリング」 - マシン・スタイルに答えます。これらの例の機能の定義が非規範的であることに注意してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability of RFC 2804 ("Raven"). . . . . . . . . . . . . 3
4. User Agent Server Behavior: Receiving a Join Header . . . . 4
5. User Agent Client Behavior: Sending a Join header . . . . . 6
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Join Header . . . . . . . . . . . . . . . . . . . 7
7.2. New option tag for Require and Supported headers . . . 8
8. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Join accepted and transitioned to central conference . 9
8.2. Join rejected . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10.1. Registration of "Join" SIP header. . . . . . . . . . . 14
10.2. Registration of "join" SIP Option-tag. . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . 15
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
This document describes a SIP [1] extension header field as part of the SIP multiparty applications architecture framework [12]. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This is especially useful in peer-to-peer call control environments.
この文書は、SIPマルチパーティアプリケーション・アーキテクチャ・フレームワーク[12]の一部としてSIP [1]拡張ヘッダフィールドを記述する。参加ヘッダは、論理的に新しいSIPダイアログで、既存のSIPダイアログを結合するために使用されます。これは、ピア・ツー・ピアのコール制御環境では特に有用です。
One use of the "Join" header is to insert a new participant into a multimedia conversation (which may be a two-party call or a SIP conference [15]). While this functionality is already available using 3rd party call control [17], style call control, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method of performing these same call control primitives in a distributed, peer-to-peer fashion is very desirable.
「参加」ヘッダの使用は（二者通話またはSIP会議[15]であってもよい）、マルチメディア会話に新しい参加者を挿入することです。この機能は、サードパーティの呼制御[17]、スタイルの呼制御を使用して、すでに利用可能ですが、3PCCモデルは、多くの環境では望ましくないことが制御の中心点が必要です。このように、分散、ピア・ツー・ピア方式で、これらの同じ呼制御プリミティブを行う方法は、非常に望ましいです。
Use of an explicit Join header is needed in some cases instead of addressing an INVITE to a conference URI for the following reasons:
明示的な参加ヘッダの使用は、代わりに次のような理由で会議URIにINVITEのアドレッシングのいくつかのケースで必要とされています。
o A conference may not yet exist--the new invitation may be trying to join an ordinary two-party call.
Oカンファレンスではまだ存在しないかもしれない - 新しい招待状は、通常の2者通話に参加しようとすることができます。
o The party joining may not know if the dialog it wants to join is part of a conference.
O当事者は、参加したいダイアログが会議の一部であるかどうかを知らないかもしれない参加します。
o The party joining may not know the conference URI.
当事者が参加するoを会議URIを知らないかもしれません。
The Join header enables services such as barge-in, real-time message screening, and call center monitoring in a distributed peer-to-peer way. This list of services is not exhaustive.
参加ヘッダは、そのような分散型ピアツーピア方法でバージイン、リアルタイム・メッセージ・スクリーニング、およびコールセンターの監視などのサービスを可能にします。サービスのこのリストは網羅的なものではありません。
For example, the Boss has an established 2-party conversation with a Customer, and using some out-of-band mechanism (e.g., voice, gestures, or email) asks an Assistant to join the conversation. The Assistant sends an INVITE with a Join header to the Boss with the dialog information for the established dialog. The Assistant obtained this information from some other mechanism, for example a web-page, an instant message, or from the SIP session dialog package [13].
例えば、ボスは、お客様との確立された2パーティの会話を持っている、といくつかのアウトオブバンドメカニズム（例えば、音声、ジェスチャー、または電子メール）を使用して会話に参加するアシスタントを要求します。アシスタントは、確立されたダイアログのダイアログ情報とボスに参加ヘッダーでINVITEを送信します。アシスタントは、いくつかの他の機構からの情報、例えば、ウェブページ、インスタントメッセージを取得し、またはSIPセッションダイアログパッケージから[13]。
Assistant Boss Customer
| callid: 4@A | callid: 7@c |
| | |
| |<============>|
| | |
|INVITE------>| |
|Join: 7@c | |
| |reINVITE----->|
|<----200-----|<----200------|
|-----ACK---->|<----ACK------|
| | |
| .. begins mixing .. |
| | |
|<===========>|<============>|
|<::::::::::::::::::::::::::>|
Note that this operation effectively creates a new conference. The Boss needs to cause a new conference to start (and consequently create or obtain a new conference URI). In our example, the Boss mixes all media locally, so it needs to generate a new conference URI, return the conference URI as the Contact to the Join INVITE (with the "isfocus" Contact header field parameter as defined in [6], and reINVITE or UPDATE [22] the Customer with the conference URI as the new Contact. This scenario is also discussed in more detail in [16].
この操作は、効果的に新しい会議を作成することに注意してください。ボスは新しい会議の開始（およびその結果として作成したり、新しい会議URIを取得）させる必要があります。それは新しい会議URIを生成する必要があるので、この例では、ボスは、ローカルにすべてのメディアをミックス[6]で定義されている「isfocus」Contactヘッダーフィールドパラメータで（INVITE参加への連絡先として会議URIを返し、新しい連絡先として会議URIをお客様にREINVITEまたはUPDATE [22]。このシナリオは、また、[16]で詳しく説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
This document refers frequently to the terms "confirmed dialog" and "early dialog". These are defined in Section 12 of SIP [1].
この文書では、用語「確認ダイアログ」と「早期ダイアログ」を頻繁に参照します。これらはSIP [1]のセクション12で定義されています。
This primitive can be used to create services which are used for monitoring purposes, however these services do not meet the definition of a wiretap according to RFC 2804 [14]. The definition from RFC 2804 is included here:
このプリミティブは、監視目的のために使用されるサービスを作成するために使用することができるが、これらのサービスは、RFC 2804による盗聴器の定義を満たさない[14]。 RFC 2804からの定義はここに含まれています：
Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party:
盗聴は、一つ以上の他の当事者に一方の当事者からインターネットを介して渡された情報は、第三者に配信されたときに発生するものです。
2. Without any of the recipient parties knowing about the delivery to the third party
第三者への配信について知る受信者の当事者のいずれかがなければ2。
3. When the normal expectation of the sender is that the transmitted information will only be seen by the recipient parties or parties obliged to keep the information in confidence
3.送信者の通常の期待が送信された情報のみを自信に情報を保持する義務が受信者の当事者または関係者によって見られることになるということです
4. When the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest.
4.第二当事者の受信に関心があるので、彼に関心がある、またはので、第三者がどちらか、ファーストパーティの伝送を対象に、意図的に機能します。
Specifically, item 2 of this definition does not apply to this extension, as one party is always aware of a Join request and can even decline such requests. In addition, in many applications of this primitive, some or all of the other items may not apply. For example, in many call centers which handle financial transactions, all conversations are recorded with the full knowledge and expectation of all parties involved.
具体的には、この定義の項目2は、一方の当事者が常に参加リクエストを認識しており、さらには、そのような要求を拒否することができますように、この拡張機能には適用されません。また、このプリミティブの多くのアプリケーションでは、他の項目の一部または全部が適用されない場合があります。例えば、金融取引を扱う多くのコールセンターでは、すべての会話は、すべての関係者の完全な知識と期待して記録されています。
The Join header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Join header, the UA attempts to match this information with a confirmed or early dialog. The to-tag and from-tag parameters are matched as if they were tags present in an incoming request. In other words the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag.
参加ヘッダは、既存のSIPダイアログを一致させるために使用される情報が含まれている（Call-IDを、対タグ、およびタグから）。参加ヘッダーでINVITEを受信すると、UAは確認または初期ダイアログで、この情報を一致させようとします。彼らは着信要求に存在するタグであるかのようにタグへとからタグのパラメータが一致しています。言い換えると、タグパラメータは、ローカルタグと比較され、よりタグのパラメータは、リモートタグと比較されます。
If more than one Join header field is present in an INVITE, or if a Join header field is present in a request other than INVITE, the UAS MUST reject the request with a 400 Bad Request response.
複数の参加ヘッダフィールドは、INVITE、または参加ヘッダーフィールドはINVITE以外の要求に存在する場合、UASは400不正な要求の応答で要求を拒絶しなければなりません。中に存在する場合
The Join header has specific call control semantics. If both a Join header field and another header field with contradictory semantics (for example a Replaces [8] header field) are present in a request, the request MUST be rejected with a 400 "Bad Request" response.
参加ヘッダは、特定の呼制御の意味を持っています。参加ヘッダフィールドと矛盾セマンティクスを持つ別のヘッダフィールドの両方が、（例えばはReplaces [8]ヘッダーフィールド）が要求に存在する場合、要求は400「不正な要求」応答で拒否されなければなりません。
If the Join header field matches more than one dialog, the UA MUST act as if no match is found.
参加ヘッダフィールドが1つのダイアログを超えると一致した場合、UAは、一致するものがないかのように行動しなければなりません。
If no match is found, but the Request-URI in the INVITE corresponds to a conference URI, the UAS MUST ignore the Join header and continue processing the INVITE as if the Join header did not exist. This allows User Agents which receive an INVITE with Join to redirect the request directly to a conference URI.
一致が見つからない場合、しかしのRequest-URI INVITE対応会議URIに、UASは、参加ヘッダを無視して、参加ヘッダが存在しなかったかのように、INVITE処理を継続しなければなりません。これは、とのINVITEを受け取るユーザエージェントが会議URIに直接リクエストをリダイレクトするために参加できます。
Otherwise if no match is found, the UAS rejects the INVITE and returns a 481 Call/Transaction Does Not Exist response. Likewise, if the Join header field matches a dialog which was not created with an INVITE, the UAS MUST reject the request with a 481 response.
一致するものがないそうでない場合、UASは、INVITE拒否し、応答存在しない481コール/トランザクションを返します。参加ヘッダーフィールドはINVITEで作成されなかったダイアログに一致した場合同様に、UASは481応答で要求を拒絶しなければなりません。
If the Join header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response.
参加ヘッダフィールドはすでに終了しているダイアログと一致した場合、UAは603拒否応答でリクエストを拒否すべきです。
If the Join header field matches an active dialog (n.b. unlike the Replaces header, the Join header has no limitation on its use with early dialogs), the UA MUST verify that the initiator of the new INVITE is authorized to join the matched dialog. If the initiator of the new INVITE has authenticated successfully as equivalent to the user who is being joined, then the join is authorized. For example, if the user being joined and the initiator of the joining dialog share the same credentials for Digest authentication [4], or they sign the join request with S/MIME [5] with the same private key and present the (same) corresponding certificate used in the original dialog, then the join is authorized.
参加ヘッダーフィールドがアクティブなダイアログと一致した場合（Replacesヘッダーとは異なりn.b.を、参加ヘッダはearlyダイアログでの使用に制限がない）、UAは新しいのイニシエータがマッチしたダイアログへの参加を許可されたINVITEことを確かめなければなりません。新しいINVITEのイニシエータが参加しているユーザーに相当すると認証に成功している場合、そのジョインは許可されています。例えば、ユーザが接合される場合と接合ダイアログ共有の開始ダイジェスト認証のために同じ資格情報[4]、またはそれらが同じ秘密鍵を使用してS / MIMEと参加要求[5]を署名し、（同じ）を提示元のダイアログで使用される証明書に対応し、インクルードが許可されて参加します。
Alternatively, the Referred-By mechanism [9] defines a mechanism that the UAS can use to verify that a join request was sent on behalf of the other participant in the matched dialog (in this case, triggered by a REFER request). If the join request contains a Referred-By header which corresponds to the user being joined, the UA SHOULD treat the join as if it was authorized by the joined party. The Referred-By header MUST reference a corresponding, valid Refererred-By Authenticated Identity Body [10]. The UA MAY apply other local policy to authorize the remainder of the request. In other words, the UAS may apply different policy to the joined dialog than was applied to the target dialog.
あるいは、[9]と呼ば-機構は（REFER要求によってトリガこの場合、）UAS参加要求が一致ダイアログ内の他の参加者に代わって送信されたことを確認するために使用できるメカニズムを定義します。参加要求は、参加しているユーザに対応呼ば-Byヘッダーが含まれている場合、UAは、それが参加者によって承認されたかのように参加扱うべきです。いうバイヘッダは、対応する、有効Refererred-によって認証アイデンティティ体[10]を参照しなければなりません。 UAはリクエストの残りを許可するために、他のローカルポリシーを適用することができます。換言すれば、UASは、ターゲットダイアログに適用されたよりも接合ダイアログに異なるポリシーを適用することができます。
The UA MAY also maintain a list of authorized entities who are allowed to join any dialog with certain characteristics (for example, all dialogs placed in the call center context of the UA). In addition, the UA MAY use other authorization mechanisms defined for this purpose in standards track extensions. For example, an extension could define a mechanism for transitively asserting authorization of a join.
UAはまた、（例えば、UAのコールセンターコンテキストに配置されたすべてのダイアログ）は、特定の特性を持つ任意のダイアログに参加することを許可された権限のエンティティのリストを維持することができます。また、UAは、標準の追跡機能拡張では、この目的のために定義された他の認証メカニズムを使用するかもしれません。例えば、拡張子が推移参加の承認を主張するためのメカニズムを定義することができます。
If authorization is successful, the UA attempts to accept the new INVITE, and assign any mixing or conferencing resources necessary to complete the join. If the UA cannot accept the new INVITE (for example: it cannot establish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged.
認証が成功した場合、UAは、新たな受け入れINVITE、および参加完了するために必要な任意の混合または会議リソースを割り当てようとします。 UAが新しいを受け入れることができない場合は、INVITE（例えば：それは必要なQoSやキーイングを確立できない、またはそれは互換性のないメディアを持っている）、UAは、適切なエラー応答を返さなければなりませんし、そのままマッチしたダイアログを残しておく必要があります。
A User Agent that accepts a Join header needs to setup dialogs or conferences such that the requesting UAC is logically added to the conversation space associated with the matched dialog. Any dialogs which are already logically associated with the matched dialog in the same conversation space are included as well. For a detailed description of various conferencing mechanisms that could be used to handle a Join, please consult the SIP conferencing framework [15].
参加ヘッダを受け入れるユーザーエージェントは、設定ダイアログまたは要求するUACは、論理的にマッチしたダイアログに関連した会話スペースに追加されるように、会議に必要。すでに論理的に同じ会話空間で一致したダイアログに関連付けられている任意のダイアログも同様に含まれています。参加を処理するために使用することができ、様々な会議メカニズムの詳細については、SIP会議フレームワーク[15]を参照してください。
If the UAS has sufficient resources to locally handle the Join request, the UAS SHOULD accept the Join request and perform the appropriate media mixing or combining. The UAS MAY rearrange appropriate dialogs instead as described below, based on some local policy.
ローカル参加要求を処理するためにUASが十分なリソースを持っている場合、UASは、参加要求を受け入れ、混合または組み合わせて適切なメディアを実行する必要があります。いくつかのローカルポリシーに基づいて、以下に説明するようにUAS代わりに適切なダイアログを再配置するかもしれません。
If the UAS does not have sufficient resources locally to handle the request, or does not wish to use these local resources, but is aware of other resources which could be used to satisfy the request (e.g., a centralized conference server), the UA SHOULD create a conference using this resource (e.g., INVITE the conference server to obtain a conference URI), redirect the requestor to this resource, and request other participants in the same conversation space to use this resource. The UA MAY use any appropriate mechanism to transition participants to the new resource (e.g., 3xx response, 3rd-party call control reinvitiations, REFER requests, or reinvitations to a multicast group). The UA SHOULD only use mechanisms which are expected to be acceptable to the other participants. For example, the UA SHOULD NOT attempt to transition the participants to a multicast group unless the UA can reasonably expect that all the participants can support multicast.
UASがリクエストを処理するために、ローカルに十分なリソースを持っていない、またはこれらのローカルリソースを使用することを望まないが、要求（例えば、集中会議サーバ）を満たすために使用することができ、他のリソースを認識している場合は、UA SHOULD （例えば、会議URIを取得するために会議サーバをINVITE）このリソースを使用して会議を作成し、このリソースへの要求者をリダイレクトし、このリソースを使用するために同じ会話空間内で他の参加を要求します。 UAは、新しいリソースへの参加者を移行するために、任意の適切なメカニズムを使用する（例えば、3XX応答、サードパーティ呼制御reinvitiations、マルチキャストグループへの要求、またはreinvitationsを参照します）。 UAは、他の参加者に許容可能であると予想されるメカニズムを使用すべきです。例えば、UAは、UAが合理的にすべての参加者がマルチキャストをサポートできることを期待することができない限り、マルチキャストグループへの参加者を移行するために試みるべきではありません。
If the UAS is incapable of satisfying the Join request, it MUST return a 488 "Not Acceptable Here" response.
UAS参加要求を満たすことができない場合は、488「ここではない許容される」応答を返さなければなりません。
A User Agent that wishes to add a new dialog of its own to a single existing early or confirmed dialog and any associated dialogs or conferences, MAY send the target User Agent an INVITE request containing a Join header field. The UAC places the Call-ID, to-tag, and from-tag information for the target dialog in a single Join header field and sends the new INVITE to the target.
単一の早期既存またはダイアログおよび関連するダイアログや会議を確認し、独自の新しいダイアログを追加したいユーザエージェントは、ターゲットユーザーエージェントに参加ヘッダフィールドを含むINVITE要求を送信することができます。 UACは、単一の参加ヘッダフィールドにターゲットダイアログのためのCall-IDにタグ、およびからタグ情報を配置して、新しいターゲットにINVITEを送信します。
If the User Agent receives a 300-class response, and acts on this response by sending an INVITE to a Contact in the response, this redirected INVITE MUST contain the same Join header which was present in the original request. Although this is unusual, this allows INVITE requests with a Join header to be redirected before reaching the target UAS.
ユーザエージェントは300クラスの応答を受信し、それに応答して連絡先にINVITEを送信することによって、この応答に作用する場合、これは元の要求に存在していた同じ参加ヘッダを含まなければならないINVITEリダイレクト。これは珍しいですが、これは参加ヘッダを持つINVITEリクエストがターゲットUASに到達する前にリダイレクトすることができます。
Note that use of the Join mechanism does not provide a way to match multiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic.
参加のメカニズムは、複数のダイアログを一致させる方法を提供していない、またそれが全体の呼び出し、トランザクション全体を一致させる方法を提供しない、またはロジックをフォークプロキシの連鎖に従うことの使用に注意してください。
Proxy Servers do not require any new behavior to support this extension. They simply pass the Join header field transparently as described in the SIP specification.
プロキシサーバは、この拡張機能をサポートするために、新しい動作を必要としません。 SIP仕様に記載されているように、それらは単に透過参加ヘッダフィールドを渡します。
Note that it is possible for a proxy (especially when forking based on some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Join header field to a completely orthogonal set of Contacts than the original request it was intended to replace. In this case, the INVITE request with the Join header field will fail.
よりコンタクトの完全直交セットに参加ヘッダフィールドを含むINVITE要求を転送する（例えば、発呼者のスクリーニングまたはtime-of-dayルーティングとして、いくつかのアプリケーション・レイヤ・ロジックに基づいて分岐する場合は特に）、プロキシが可能であることに注意してください元の要求は、それを置き換えることを意図していました。この場合、参加ヘッダフィールドでINVITEリクエストを失敗します。
The Join header field indicates that a new dialog (created by the INVITE in which the Join header field in contained) should be joined with a dialog identified by the header field, and any associated dialogs or conferences. It is a request header only, and defined only for INVITE requests. The Join header field MAY be encrypted as part of end-to-end encryption. Only a single Join header field value may be present in a SIP request
参加ヘッダフィールドは、新しいダイアログヘッダフィールドによって識別ダイアログ、および関連するダイアログや会議に接合しなければならない（で作成されたが、その中に含まれるに参加ヘッダフィールドはINVITE）ことを示しています。それが唯一のリクエストヘッダであり、そして唯一のINVITE要求のために定義されました。参加ヘッダフィールドは、エンドツーエンドの暗号化の一環として、暗号化されてもよいです。単一の参加ヘッダーフィールド値は、SIP要求の中に存在してもよいです
This document adds the following entry to Table 3 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined respectively in [19], [20], [7], [21], [22], [23], and [24].
この文書では、[1]の表3に次のエントリを追加します。このテーブルへの追加は、この文書の発行時点で定義された拡張メソッドのために提供されます。これは、読者への礼儀として提供され、どのような方法で規範的ではありません。 MESSAGE、SUBSCRIBE及びNOTIFY、REFER、INFO、UPDATE、PRACK、及びPUBLISH [19]にそれぞれ定義されている、[20]、[7]、[21]、[22]、[23]及び[24]。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Join R - - - o - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
Join R - - - - - - -
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [3].
以下の構文仕様はRFC 2234に記載されているように拡張バッカスナウア記法（BNF）を使用する[3]。
Join = "Join" HCOLON callid *(SEMI join-param) join-param = to-tag / from-tag / generic-param to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token
= EQUAL "からタグ" HCOLON callid *からタグ=（SEMI参加-param）は参加-PARAM =へのタグ/からタグ/ジェネリック-PARAMにタグ= "へのタグ" EQUALトークンを "参加" に参加トークン
A Join header MUST contain exactly one to-tag and exactly one from-tag, as they are required for unique dialog matching. For compatibility with dialogs initiated by RFC 2543 [11] compliant UAs, a to-tag of zero matches both a to-tag value of zero and a null to-tag. Likewise, a from-tag of zero matches both a to-tag value of zero and a null from-tag.
彼らは独自のダイアログマッチングのために必要とされるとして参加ヘッダは、にタグ正確に一つとからタグ正確に一つを含まなければなりません。 RFC 2543 [11]準拠のUA、ゼロにタグゼロマッチのにタグ値の両方とにタグヌルによって開始ダイアログとの互換性のため。同様に、ゼロマッチゼロにタグ値とからタグヌルの両方からタグ。
Examples:
例：
Join: 98732@sip.example.com ;from-tag=r33th4x0r ;to-tag=ff87ff
参加：98732@sip.example.com;からタグ= r33th4x0r;にタグ= ff87ff
Join: 12adf2f34456gs5;to-tag=12345;from-tag=54321
参加：12adf2f34456gs5;にタグ= 12345;からタグ= 54321
Join: 87134@192.0.2.23;to-tag=24796;from-tag=0
参加：87134@192.0.2.23;にタグ= 24796;からタグ= 0
This specification defines a new Require/Supported header option tag "join". UAs which support the Join header MUST include the "join" option tag in a Supported header field. UAs that want explicit failure notification if Join is not supported MAY include the "join" option in a Require header field.
この仕様は、新たなサポート/ Requireヘッダーオプションタグ「参加」を定義します。参加ヘッダをサポートするUAは、Supportedヘッダーフィールドに「参加する」オプションタグを含まなければなりません。参加場合は、明示的な失敗の通知を希望するUAはサポートされていませんがRequireヘッダーフィールドにオプションを「参加」を含むことができます。
Example:
例：
Require: join, 100rel
必要：参加、100rel
The following non-normative examples are not intended to enumerate all the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see service-examples [18].
以下の非規範的な例は、この拡張機能の使用方法についてあらゆる可能性を列挙するのではなく、単なる例やアイデアを提供することを意図していません。その他の例については、サービスの例[18]を参照してください。
A B C conf
| | callid: 7@c | |
| | | |
| |<-INVITE------| | *1
| |-----200----->| | *2
| |<----ACK------| | *3
| |<============>| |
| | | |
|INVITE------>| | | *4
|Join: 7@c |--INVITE-------------------->| *5
| |<----200---------------------| *6
| |-----ACK-------------------->|
|<----302-----| | | *7
|-----ACK---->| | |
|INVITE------------------------------------>| *8
|<--200-------------------------------------| *9
|---ACK------------------------------------>|
| |--REFER------>| | *10
| |<---202-------| |
| |<--NOTIFY-----|--INVITE-*11->|
| |------200---->|<----200-*12--|
| |<--NOTIFY-----|-----ACK----->|
| |------200---->| |
| |---BYE------->| |
| |<--200--------| |
| | | |
|<=========================================>| mixes the
| |<===========================>| three sessions
| | |<============>| together
The conversation now appears identical to the locally mixed one from the example in the Introduction. Details of how the Join are implemented are transparent to A. B could have used 3rd party call control instead to move the necessary sessions.
会話は今、はじめの例からローカルに混合したものと同じ表示されます。実装されている参加方法の詳細は、AのBへの透過が必要なセッションを移動する代わりに、サードパーティの呼制御を使用している可能性があります。
Message *1: C -> B
メッセージ* 1：C - > B
INVITE sip:bob@example.org SIP/2.0 To: <bob@example.org> From: <carol@example.org>;tag=xyz Call-Id: 7@c.example.org CSeq 1 INVITE Contact: <sip:carol@c.example.org>
タグ= XYZのコールID; <carol@example.org>：7@c.example.orgのCSeq連絡先を1 INVITE：<bob@example.org SIP / 2.0：<bob@example.org>からのSIPのINVITE SIP：carol@c.example.org>
Message *2: B -> C
メッセージ* 2：B - > C
SIP/2.0 200 OK To: <bob@example.org>;tag=pdq From: <carol@example.org>;tag=xyz Call-Id: 7@c.example.org CSeq 1 INVITE Contact: <sip:bob@b.example.org>
SIP / 2.0 200 OK：<bob@example.org>;タグ= PDQから：<carol@example.org>;タグ= XYZのコールID：7@c.example.orgのCSeq 1の接触INVITE：<一口： bob@b.example.org>
Message *3: C -> B
メッセージ* 3：C - > B
ACK sip:carol@c.example.org SIP/2.0 To: <bob@example.org>;tag=pdq From: <carol@example.org>;tag=xyz Call-Id: 7@c.example.org CSeq 1 INVITE
ACKをSIP：carol@c.example.org SIP / 2.0 <bob@example.org>;タグ= PDQから<carol@example.org>;タグ= XYZのコールID：7@c.example.org CSeq 1 INVITE
Message *4: A -> B
メッセージ* 4：A - > B
INVITE sip:bob@b.example.org SIP/2.0 To: <sip:bob@example.org> From: <sip:alice@example.org>;tag=iii Call-Id: 777@a.example.org CSeq: 1 INVITE Contact: <sip:alice@a.example.org> Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
777@a.example.org; bob@b.example.org SIP / 2.0：<SIP：bob@example.org>から：タグ= IIIコールID：<SIP alice@example.org> SIPのINVITE CSeq：連絡先1 INVITE：<SIP：alice@a.example.org>に参加：7@c.example.orgを;にタグ= XYZ;からタグ= PDQ
Message *5: B -> conf
メッセージ* 5：B - > CONF
INVITE sip:conf-factory@example.org SIP/2.0 To: <sip:conf-factory@example.org> From: <sip:bob@example.org>;tag=abc Call-Id: 999@b.example.org CSeq: 1INVITE Contact: <sip:bob@b.example.org>
<conf-factory@example.org SIP：>：TO conf-factory@example.org SIP / 2.0：SIPのINVITE <SIP：bob@example.org>;タグ= ABCコールID：999@b.example .ORGのCSeq：1INVITE連絡先：<SIP：bob@b.example.org>
Message *6: conf -> B
メッセージ* 6：CONF - > B
SIP/2.0 200 OK To: <sip:conf-factory@example.org>;tag=def From: <sip:bob@example.org>;tag=abc Call-Id: 999@b.example.org CSeq: 1INVITE Contact: <sip:conf456@conf-srv2.example.org>;isfocus
SIP / 2.0 200 OKに<SIP：conf-factory@example.org>;タグ= DEFから<SIP：bob@example.org>;タグ= ABCコールID：999@b.example.orgのCSeq： 1INVITE連絡先：<SIP：conf456@conf-srv2.example.org>; isfocus
Message *7: B -> A
メッセージ* 7：B - > A
SIP/2.0 302 Moved Temporarily To: <sip:bob@example.org> From: <sip:alice@example.org>;tag=iii Call-Id: 777@a.example.org CSeq: 1 INVITE Contact: <sip:conf456@conf-srv2.example.org>;isfocus
SIP / 2.0 302に一時的に移動：<SIP：bob@example.org>から：;接触INVITE 1：<SIP alice@example.org>タグ= IIIコールID：777@a.example.orgのCSeq < SIP：conf456@conf-srv2.example.org>; isfocus
Message *8: A -> conf
メッセージ* 8：A - > CONF
INVITE sip:conf456@conf-srv2.example.org SIP/2.0 To: <sip:bob@example.org> From: <sip:alice@example.org>;tag=iii Call-Id: 777@a.example.org CSeq: 2 INVITE Contact: <sip:alice@a.example.org> Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
<bob@example.org SIP：>：TO conf456@conf-srv2.example.org SIP / 2.0：SIPのINVITE <SIP：alice@example.org>;タグは= IIIコールID：777@a.example .orgのCSeq：<SIP：alice@a.example.org>参加：連絡先INVITE 2 7@c.example.org;にタグ= XYZ;からタグ= PDQを
Message *9: conf ->A
メッセージ* 9：CONF - > A
SIP/2.0 200 OK To: <sip:bob@example.org>;tag=jjj From: <sip:alice@example.org>;tag=iii Call-Id: 777@a.example.org CSeq: 2 INVITE Contact: <sip:conf456@conf-srv2.example.org>;isfocus
SIP / 2.0 200 OK <SIP：bob@example.org>;タグはJJJから= <SIP：alice@example.org>;タグ= IIIコールID：777@a.example.orgのCSeq：INVITE 2連絡先：<SIP：conf456@conf-srv2.example.org>; isfocus
Message *10: B -> C
メッセージ* 10：B - > C
REFER sip:carol@c.example.org SIP/2.0 To: <carol@example.org>;tag=xyz From: <bob@example.org>;tag=pdq Call-Id: 7@c.example.org CSeq: 1 REFER Contact: <sip:bob@b.example.org> Refer-To: <sip:conf456@conf-srv2.example.org> Referred-By: <sip:bob@b.example.org>
REFER SIP：carol@c.example.org SIP / 2.0 <carol@example.org>;タグ=からXYZ <bob@example.org>;タグ= PDQコール-ID：7@c.example.org CSeq：連絡先を1参照：<SIP：bob@b.example.org>参照してください-TO：<SIP：conf456@conf-srv2.example.org>と呼ばバイ：<SIP：bob@b.example.org>
Message *11: C -> conf
メッセージ* 11：C - > CONF
INVITE sip:conf456@conf-srv2.example.org SIP/2.0 To: <sip:conf456@conf-srv2.example.org> From: <carol@example.org>;tag=mmm
<conf456@conf-srv2.example.org SIP：>：TO conf456@conf-srv2.example.org SIP / 2.0：SIPのINVITE <carol@example.org>;タグ= MMM
Call-Id: 34343@c.example.com CSeq: 1 INVITE Contact: <sip:carol@c.example.com> Referred-By: <sip:bob@b.example.org>
コールID：34343@c.example.comのCSeqは：連絡先を1 INVITE：<SIP：carol@c.example.com>と呼ばバイ：<SIP：bob@b.example.org>
Message *12: C -> conf
メッセージ* 12：C - > CONF
SIP/2.0 200 OK To: <sip:conf456@conf-srv2.example.org> From: <carol@example.org>;tag=mmm Call-Id: 34343@c.example.com CSeq: 1 INVITE Contact: <sip:conf456@conf-srv2.example.org>;isfocus Referred-By: <sip:bob@b.example.org>
SIP / 2.0 200 OKに：<SIP：conf456@conf-srv2.example.org>から<carol@example.org>;タグ= MMMコールID：34343@c.example.comのCSeq：連絡先を1 INVITE： <一口：conf456@conf-srv2.example.org>;呼ば-BYはisfocus：<SIP：bob@b.example.org>
A B C
| | callid: 7@c |
| | |
| |<============>|
| | |
|INVITE------>| *1 |
|Join: 7@c | |
| | |
|<----486-----| *2 |
|-----ACK---->| |
| | |
In this example B is Busy (does not want to be disturbed), and therefore does not wish to add A. B could also decline the request with a 603 response.
この例では、Bは、（邪魔されたくない）ビジーであるため、また、603応答で要求を断ることができA. Bを追加したくありません。
Message *1: A -> B
メッセージ* 1：A - > B
INVITE sip:bob@b.example.org SIP/2.0 To: <sip:bob@example.org> From: <sip:alice@example.org>;tag=iii Call-Id: 777@a.example.org CSeq: 1 INVITE Contact: <sip:alice@a.example.org> Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
777@a.example.org; bob@b.example.org SIP / 2.0：<SIP：bob@example.org>から：タグ= IIIコールID：<SIP alice@example.org> SIPのINVITE CSeq：連絡先1 INVITE：<SIP：alice@a.example.org>に参加：7@c.example.orgを;にタグ= XYZ;からタグ= PDQ
Message *2: B -> A
メッセージ* 2：B - > A
SIP/2.0 486 Busy To: <sip:bob@example.org> From: <sip:alice@example.org>;tag=iii Call-Id: 777@a.example.org CSeq: 1 INVITE
SIP / 2.0 486ビジーに<SIP：bob@example.org>から<SIP：alice@example.org>;タグ= IIIコールID：777@a.example.orgのCSeq：INVITE 1
The extension specified in this document significantly changes the relative security of SIP devices. Currently in SIP, even if an eavesdropper learns the Call-ID, To, and From headers of a dialog, they cannot easily modify or destroy that dialog if Digest authentication or end-to-end message integrity are used.
この文書で指定された拡張子を大幅にSIPデバイスの相対的なセキュリティを変更します。現在、SIPで、盗聴者は、Call-IDは、に、学習した場合でも、ダイアログのヘッダから、彼らは簡単に変更したり、ダイジェスト認証やエンドツーエンドのメッセージの完全性が使用されている場合は、そのダイアログを破壊することはできません。
This extension can be used to insert or monitor potentially sensitive content in a multimedia conversation. As such, invitations with the Join header MUST only be accepted if the peer requesting replacement has been properly authenticated using a standard SIP mechanism (Digest or S/MIME), and authorized to be joined with the target dialog. (All SIP implementations are already required to support Digest Authentication.) Generally authorization for joins are configured as a matter of local policy as long-duration persistent relationships.
この拡張は、マルチメディア会話の中で潜在的に敏感なコンテンツを挿入したり、監視するために使用することができます。ピア要求交換が適切に標準のSIPメカニズム（ダイジェストまたはS / MIME）を使用して認証し、ターゲットダイアログに接合することが許可されている場合など、参加ヘッダを持つ招待のみを受け入れなければなりません。 （すべてのSIPの実装は、すでにダイジェスト認証をサポートする必要があります。）参加するための一般的承認が長時間持続的関係などのローカルポリシーの問題として設定されています。
For example, the UAs used by call center agents might be configured with a list of identities who could join their calls (supervisors and any call center monitoring User Agents). Alternatively the call center agents might rely on transitive authorization assertions from a (shorter) list of authorized hosts (e.g., a certificate authority). For answering-machine-style message screening this is even easier. Presumably the user screening their messages already has some credentials with their messaging server.
例えば、コールセンターのエージェントによって使用されるUAはそのコール（上司や任意のコールセンター監視ユーザエージェント）に参加できたIDのリストで構成されることがあります。また、コールセンターのエージェントは、許可するホスト（例えば、認証局）の（短い）リストから、推移認証アサーションに依存しているかもしれません。スクリーニング答えるマシン・スタイルのメッセージについては、これはさらに簡単です。おそらく彼らのメッセージをスクリーニングしたユーザは、すでに自分のメッセージングサーバといくつかの資格情報を持っています。
Some mechanisms for obtaining the dialog information needed by the Join header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, and notifications after a REFER request. Use of end-to-end security mechanisms to integrity protect and encrypt this information is also RECOMMENDED.
参加ヘッダーで必要なダイアログ情報を取得するためのいくつかのメカニズムは、（コールIDを、とタグ、およびからタグ）Webページ上のURI、適切なイベントパッケージへのサブスクリプション、およびREFERリクエストの後に通知があります。この情報を保護し、暗号化の整合性へのエンドツーエンドのセキュリティメカニズムの使用も推奨されます。
This extension was designed to take advantage of future signature or authorization schemes defined by standards track extensions. In general, call control features would benefit considerably from such work.
この拡張は、標準化トラックの拡張によって定義された将来の署名や認証制度を活用するように設計されました。一般的には、呼制御機能は、このような作業から大幅に利益を得るであろう。
Section 4 describes specific mechanisms for authorization using Digest Authentication and S/MIME (RFC 3261) and Referred-by [9], the currently available capabilities in SIP.
セクション4は、ダイジェスト認証およびS / MIME（RFC 3261）を使用して承認するための特定のメカニズムを説明呼ば-によってSIPで[9]、現在利用可能な機能。
Name of Header: Join
ヘッダーの名前：参加
Short form: none
短い形式：なし
Normative description: section 7.1 of this document
規範的な説明：この文書のセクション7.1
Name of option: join
オプションの名前：参加
Description: Support for the SIP Join header
説明：SIPのサポートは、ヘッダに参加します
SIP headers defined: Join
SIPヘッダが定義された：参加します
Normative description: This document
規範的な説明：この文書
Thanks to Robert Sparks, Alan Johnston, and Ben Campbell and many other members of the SIP WG for their continued support of the cause of distributed call control in SIP.
ロバート・スパークス、アラン・ジョンストン、そしてベン・キャンベルとSIPにおける分散呼制御の原因の彼らの継続的な支援のためのSIP WGの多くの他のメンバーに感謝します。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[4]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[5] Ramsdell、B.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[6] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[6]ローゼンバーグ、J.、 "セッション開始プロトコルで示すユーザエージェント機能（SIP）"、RFC 3840、2004年8月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[8] Dean, R., Biggs, B., and R. Mahy, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[8]ディーン、R.、ビッグス、B.、およびR.マーイは、 "セッション開始プロトコル（SIP） "は、" ヘッダ" を置き換えRFC 3891、2004年9月。
[9] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[9]、R.、 "セッション開始プロトコル（SIP）と呼ば-メカニズム"、RFC 3892、2004年9月スパークス。
[10] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[10]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。
[11] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[11]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[12] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[12]マーイ、R.、「コール制御およびセッション開始プロトコル（SIP）のためのマルチパーティの使用フレームワーク」、進歩、2003年3月での作業。
[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[13]ローゼンバーグ、J.とH. Schulzrinneと、「セッション開始プロトコル（SIP）のために開始INVITEダイアログイベントパッケージ」、進歩、2003年3月での作業。
[14] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[14] IABとIESG、 "盗聴のIETF方針"、RFC 2804、2000年5月。
[15] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003.
[15]ローゼンバーグ、J.、「セッション開始プロトコルとの会議のための枠組み」、進歩、2003年5月での作業。
[16] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, April 2003.
[16]ジョンストン、A.、およびO.レヴィン、「セッション開始プロトコル呼制御 - ユーザエージェントのための会議」、進歩、2003年4月の作業。
[17] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[17]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[18] Johnston, A. and S. Donovan, "Session Initiation Protocol Service Examples", Work in Progress, March 2003.
[18]ジョンストン、A.、およびS.ドノバン、「セッション開始プロトコルサービスの例」、進歩、2003年3月での作業。
[19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[19]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[20] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[20]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[21] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[21]ドノヴァン、S.、 "SIP INFO方法"、RFC 2976、2000年10月。
[22] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[22]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
、RFC 3262、2002年6月[23]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[24] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in Progress, February 2003.
[24]キャンベル、B.、 "SIMPLEプレゼンス公開メカニズム"、進歩、2003年2月に作業。
Rohan Mahy Airespace 110 Nortech Parkway San Jose, CA 95134 USA
ロハンマーイAirespaceの110 Nortechパークウェイサンノゼ、CA 95134 USA
EMail: rohan@airespace.com
メールアドレス：rohan@airespace.com
Dan Petrie Pingtel 400 West Cummings Park, Suite 2200 Woburn, MA 01801 USA
ダン・ペトリーPingtel 400西カミングス公園、スイート2200ウォバーン、MA 01801 USA
EMail: dpetrie@pingtel.com
メールアドレス：dpetrie@pingtel.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。