[要約] RFC 3911は、SIPプロトコルの拡張である「Join」ヘッダーに関するものです。このヘッダーは、複数のセッションを結合するために使用され、セッションの参加者を制御するための機能を提供します。目的は、SIPベースのアプリケーションでのセッションの結合と管理を容易にすることです。
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
セッション開始プロトコル（SIP）「結合」ヘッダー
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）The Internet Society（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 [1]拡張ヘッダーフィールドについて、SIPマルチパルティアプリケーションアーキテクチャフレームワークの一部として説明しています[12]。結合ヘッダーは、新しい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.
「参加」ヘッダーの1つの使用は、新しい参加者をマルチメディアの会話に挿入することです（これは2パーティの電話または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への招待に対処する代わりに、明示的な結合ヘッダーの使用が必要です。
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.
Join Headerは、分散ピアツーピアの方法で、バージイン、リアルタイムメッセージスクリーニング、コールセンターの監視などのサービスを有効にします。このサービスリストは網羅的ではありません。
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パーティの会話をしており、バンド外のメカニズム（音声、ジェスチャー、電子メールなど）を使用すると、アシスタントに会話に参加するように依頼します。アシスタントは、確立されたダイアログのダイアログ情報を使用して、ボスに招待状を招待します。アシスタントは、この情報を他のメカニズム、たとえばWebページ、インスタントメッセージ、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を生成し、Joinの招待状（[6]で定義されている「IsFocus」連絡ヘッダーフィールドパラメーターを使用して、会議URIを返す必要があります。ReinviteまたはUpdate [22]新しい連絡先としての会議URIの顧客。このシナリオについては、[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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:
盗聴は、1つの当事者から1つ以上の他の当事者にインターネットを越えて情報を渡されたときに発生することです。
1. Without the sending party knowing about the third party 2. Without any of the recipient parties knowing about the delivery to the third party
1. 送信当事者がサードパーティについて知らない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はこの拡張機能には適用されません。1つの当事者は常に参加要求を認識しており、そのようなリクエストを拒否することさえできます。さらに、この原始の多くのアプリケーションでは、他のアイテムの一部またはすべてが適用されない場合があります。たとえば、金融取引を処理する多くのコールセンターでは、すべての会話が関係するすべての当事者の完全な知識と期待を持って記録されます。
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.
Join Headerには、既存のSIPダイアログ（Call-ID、To-Tag、From Tag）に一致するために使用される情報が含まれています。Join Headerで招待状を受け取ると、UAはこの情報を確認されたまたは初期のダイアログと一致させようとします。To-TagおよびTagのパラメーターは、着信リクエストに存在するタグであるかのように一致します。言い換えれば、to-tagパラメーターはローカルタグと比較され、From-TAGパラメーターはリモートタグと比較されます。
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.
招待状に複数のJoin Headerフィールドが存在する場合、または招待以外のリクエストにJoin Headerフィールドが存在する場合、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.
結合ヘッダーには、特定のコールコントロールセマンティクスがあります。Join Headerフィールドと矛盾したセマンティクスを備えた別のヘッダーフィールド（たとえば、置換[8]ヘッダーフィールド）の両方がリクエストに存在する場合、リクエストは400の「悪い要求」応答で拒否する必要があります。
If the Join header field matches more than one dialog, the UA MUST act as if no match is found.
Join Headerフィールドが複数のダイアログと一致する場合、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.
一致が見つからないが、招待状のリクエスト-URIが会議URIに対応する場合、UASは結合ヘッダーを無視し、結合ヘッダーが存在しないかのように招待を処理し続ける必要があります。これにより、Joinで招待状を受け取ったユーザーエージェントが、リクエストを会議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は招待状を拒否し、481のコール/トランザクションを返します。応答は存在しません。同様に、Join Headerフィールドが招待状で作成されなかったダイアログと一致する場合、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.
Join Headerフィールドがすでに終了しているダイアログと一致する場合、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.
Join Headerフィールドがアクティブなダイアログと一致する場合（N.B.の交換ヘッダーとは異なり、Join Headerは初期ダイアログでの使用に制限がありません）、UAは、新しい招待の開始者がマッチングされたダイアログに参加することを許可されていることを確認する必要があります。新しい招待のイニシエーターが、参加中のユーザーに相当するものとして正常に認証された場合、結合は承認されます。たとえば、参加しているユーザーと参加ダイアログのイニシエーターがダイジェスト認証のために同じ資格情報を共有する場合、または同じ秘密鍵で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]は、UASが一致したダイアログの他の参加者に代わって送信されたことを確認するためにUASが使用できるメカニズムを定義します（この場合、紹介要求によってトリガーされます）。Joinリクエストに、参加中のユーザーに対応する紹介されたヘッダーが含まれている場合、UAは参加者によって承認されたかのように参加を扱う必要があります。紹介されたヘッダーは、対応する、有効な紹介された認証されたアイデンティティ本体[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は新しい招待を受け入れ、参加を完了するために必要なミキシングまたは会議リソースを割り当てようとします。UAが新しい招待状を受け入れられない場合（たとえば、必要な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].
Join Headerを受け入れるユーザーエージェントは、リクエスト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はUAが必要ですこのリソースを使用して会議を作成し（例：会議サーバーを招待して会議URIを取得します）、リクエスターをこのリソースにリダイレクトし、同じ会話スペースの他の参加者にこのリソースを使用するよう要求します。UAは、適切なメカニズムを使用して、参加者を新しいリソースに移行することができます（例：3xx応答、第3パーティコールコントロールの再vitiation、リクエストの参照、またはマルチキャストグループへの再啓発）。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.
独自の新しいダイアログを1つの既存の早期または確認されたダイアログおよび関連するダイアログまたは会議に追加したいユーザーエージェントは、ターゲットユーザーエージェントにJoin Headerフィールドを含む招待リクエストを送信する場合があります。UACは、Call-ID、To-Tag、およびターゲットダイアログのTAG情報を単一の結合ヘッダーフィールドに配置し、新しい招待状をターゲットに送信します。
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クラスの応答を受信し、応答の連絡先に招待状を送信することでこの応答に基づいて行動する場合、このリダイレクトされた招待状には、元のリクエストに存在する同じ結合ヘッダーが含まれている必要があります。これは珍しいことですが、これにより、ターゲット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仕様に記載されているように、Join Headerフィールドを透過的に渡すだけです。
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.
プロキシが可能であることに注意してください（特に、発信者のスクリーニングや時刻ルーティングなどのアプリケーションレイヤーロジックに基づいてフォークする場合）。元のリクエストは、交換することを目的としていました。この場合、Join Headerフィールドでの招待リクエストは失敗します。
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
Join Headerフィールドは、新しいダイアログ（接続ヘッダーフィールドが含まれる招待状によって作成された）を、ヘッダーフィールドによって識別されたダイアログと、関連するダイアログまたは会議で結合する必要があることを示します。これはリクエストヘッダーのみであり、招待リクエストのみで定義されています。結合ヘッダーフィールドは、エンドツーエンド暗号化の一部として暗号化される場合があります。SIPリクエストには1つの結合ヘッダーフィールド値のみが存在する場合があります
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に追加します。このテーブルへの追加は、このドキュメントの公開時に定義された拡張方法についても提供されます。これは読者への礼儀として提供され、いかなる方法でも規範的ではありません。メッセージ、購読、通知、紹介、情報、更新、プラック、およびパブリッシュは、それぞれ[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].
sub not ref ref inf upd pra pub ---- --- --- --------- r-----------次の構文仕様では、拡張されたバックスノーフォーム（bnf）を使用します）RFC 2234 [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
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.
結合ヘッダーには、一意のダイアログマッチングに必要なため、正確に1つのToタグとタグから1つのタグが1つ含まれている必要があります。RFC 2543 [11]準拠のUASによって開始されたダイアログとの互換性については、ゼロの値とゼロの両方のゼロとnull toタグの両方が一致します。同様に、ゼロのタグからのタグは、ゼロのタグ値とタグからのnullの両方を一致させます。
Examples:
例：
Join: 98732@sip.example.com
;from-tag=r33th4x0r
;to-tag=ff87ff
Join: 12adf2f34456gs5;to-tag=12345;from-tag=54321
Join: 87134@192.0.2.23;to-tag=24796;from-tag=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.
この仕様は、新しい要求/サポートヘッダーオプションタグ「Join」を定義します。結合ヘッダーをサポートするUASは、サポートされているヘッダーフィールドに「結合」オプションタグを含める必要があります。JOINがサポートされていない場合に明示的な障害通知を必要とするUASには、必要なヘッダーフィールドに「結合」オプションが含まれる場合があります。
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].
次の非規範的な例は、この拡張機能の使用の可能性をすべて列挙することではなく、例やアイデアのみを提供することを目的としています。その他の例については、Service-Examples [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に対して透明です。Bは、代わりにサードパーティのコールコントロールを使用して、必要なセッションを移動しました。
Message *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>
Message *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>
Message *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
Message *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
Message *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>
Message *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
Message *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
Message *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
Message *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
Message *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>
Message *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
Call-Id: 34343@c.example.com
CSeq: 1 INVITE
Contact: <sip:carol@c.example.com>
Referred-By: <sip:bob@b.example.org>
Message *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>
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は忙しい（邪魔されたくない）ため、Aを追加することは望ましくありません。
Message *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
Message *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
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では、盗聴者がダイアログのヘッダーを、およびヘッダーから、コールアイドを学習したとしても、認証またはエンドツーエンドのメッセージの整合性が使用されている場合、そのダイアログを簡単に変更または破壊することはできません。
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メカニズム（DigestまたはS/Mime）を使用してピアリクエストの交換品が適切に認証され、ターゲットダイアログに加わることを許可されている場合にのみ、Join Headerによる招待状を受け入れる必要があります。（すべての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.
たとえば、コールセンターのエージェントが使用するUASは、電話（監督者とコールセンター監視ユーザーエージェント）に参加できるアイデンティティのリストで構成される場合があります。あるいは、コールセンターのエージェントは、認定ホストの（より短い）リスト（たとえば、証明書当局）からの推移的な承認アサーションに依存する場合があります。マシンスタイルのメッセージスクリーニングに答えるには、これがさらに簡単です。おそらく、メッセージをスクリーニングするユーザーは、メッセージングサーバーを使用してすでにいくつかの資格情報を持っています。
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.
Join Header（Call-ID、To-Tag、およびFrom-Tag）が必要とするダイアログ情報を取得するためのいくつかのメカニズムには、Webページ上のURI、適切なイベントパッケージへのサブスクリプション、紹介要求後の通知が含まれます。エンドツーエンドのセキュリティメカニズムを整合性に保護および暗号化するために使用することもお勧めします。
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では、SIPで現在利用可能な機能であるDigest認証とS/MIME（RFC 3261）および参照[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 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「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。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[6] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[6] Rosenberg、J。、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] Sparks、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] Dean、R.、Biggs、B。、およびR. Mahy、「セッション開始プロトコル（SIP）」「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[9] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[9] Sparks、R。、「セッション開始プロトコル（SIP）がメカニズムを参照」、RFC 3892、2004年9月。
[10] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[10] Peterson、J。、「セッション開始プロトコル（SIP）認証IDボディ（AIB）形式」、RFC 3893、2004年9月。
[11] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[11] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、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] Mahy、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] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）の招待開始されたダイアログイベントパッケージ」、2003年3月、Work in Progress。
[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] Rosenberg、J。、「セッション開始プロトコルとの会議のためのフレームワーク」、2003年5月、進行中の作業。
[16] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, April 2003.
[16] Johnston、A。およびO. Levin、「セッション開始プロトコルコールコントロール - ユーザーエージェントの会議」、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] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）の第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[18] Johnston, A. and S. Donovan, "Session Initiation Protocol Service Examples", Work in Progress, March 2003.
[18] Johnston、A。、およびS. Donovan、「セッション開始プロトコルサービスの例」、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] Campbell、B.、Rosenberg、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] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[21] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[21] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[22] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[22] Rosenberg、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.
[23] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[24] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in Progress, February 2003.
[24] Campbell、B。、「Simple Presencion Publication Mechanism」、Progress、2003年2月。
Rohan Mahy Airespace 110 Nortech Parkway San Jose, CA 95134 USA
Rohan Mahy Airespace 110 Nortech Parkway San Jose、CA 95134 USA
EMail: rohan@airespace.com
Dan Petrie Pingtel 400 West Cummings Park, Suite 2200 Woburn, MA 01801 USA
Dan Petrie Pingtel 400 West Cummings Park、Suite 2200 Woburn、MA 01801 USA
EMail: dpetrie@pingtel.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。