RFC 4916 - Connected Identity in the Session Initiation Protocol (SIP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4916
タイトル : RFC 4916 - セッション開始プロトコル（SIP）の接続アイデンティティ
翻訳編集 : 自動生成

[要約] RFC 4916は、SIPにおける接続されたアイデンティティに関する規格であり、セッションの開始時にアイデンティティ情報を提供するための仕組みを定義しています。このRFCの目的は、SIPセッションにおけるアイデンティティ情報の信頼性とセキュリティを向上させることです。

Network Working Group                                          J. Elwell
Request for Comments: 4916     Siemens Enterprise Communications Limited
Updates: 3261                                                  June 2007
Category: Standards Track

Connected Identity in the Session Initiation Protocol (SIP)

セッション開始プロトコル（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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The IETF Trust（2007）。

Abstract

概要

This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP).

このドキュメントは、セッション開始プロトコル（SIP）ユーザーエージェント（UA）の手段を提供します。これは、逆方向のリクエストにより、およびそのアイデンティティに署名するために、ピアUAにIDを提供するダイアログ形成リクエストを受信します。認証サービスによって。ダイアログ形成リクエスト（リクエスト-URIの値の変更）のリターゲティングのため、それを受信するUA（ユーザーエージェントサーバー、UAS）は、ヘッダーフィールドのそれとは異なるアイデンティティを持つことができます。同じメカニズムを使用して、ダイアログ中のアイデンティティの変化を示すことができます。たとえば、ゲートウェイの背後にある公開された電話ネットワーク（PSTN）での何らかのアクションのためです。このドキュメントは、RFC 3261（SIP）を規範的に更新します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of Solution . . . . . . . . . . . . . . . . . . . . .  4
   4.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Behaviour of a UA that Issues an INVITE Request
           Outside the Context of an Existing Dialog  . . . . . . . .  6
     4.2.  Behaviour of a UA that Receives an INVITE Request
           outside the Context of an Existing Dialog  . . . . . . . .  6
     4.3.  Behaviour of a UA Whose Identity Changes during an
           Established INVITE-initiated Dialog  . . . . . . . . . . .  7
     4.4.  General UA Behaviour . . . . . . . . . . . . . . . . . . .  7
       4.4.1.  Sending a Mid-Dialog Request . . . . . . . . . . . . .  7
       4.4.2.  Receiving a Mid-Dialog Request . . . . . . . . . . . .  8
     4.5.  Authentication Service Behaviour . . . . . . . . . . . . .  8
     4.6.  Verifier Behaviour . . . . . . . . . . . . . . . . . . . .  9
     4.7.  Proxy Behaviour  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Sending Connected Identity after Answering a Call  . . . . 10
     5.2.  Sending Revised Connected Identity during a Call . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23

1. Introduction

1. はじめに

The Session Initiation Protocol (SIP) (RFC 3261 [1]) initiates sessions but also provides information on the identities of the parties at both ends of a session. Users need this information to help determine how to deal with communications initiated by a SIP. The identity of the party who answers a call can differ from that of the initial called party for various reasons such as call forwarding, call distribution and call pick-up. Furthermore, once a call has been answered, a party can be replaced by a different party with a different identity for reasons such as call transfer, call park and retrieval, etc. Although in some cases there can be reasons for not disclosing these identities, it is desirable to have a mechanism for providing this information.

セッション開始プロトコル（SIP）（RFC 3261 [1]）はセッションを開始するだけでなく、セッションの両端で当事者のアイデンティティに関する情報も提供します。ユーザーは、SIPによって開始されたコミュニケーションに対処する方法を決定するためにこの情報が必要です。通話に応答する当事者の身元は、コール転送、コールディストリビューション、コールピックアップなど、さまざまな理由で、最初のコールパーティーのアイデンティティとは異なる場合があります。さらに、コールに応答すると、コール転送、コールパーク、検索などの理由により、別の当事者に別の当事者に置き換えることができます。この情報を提供するためのメカニズムを持つことが望ましいです。

This document extends the use of the From header field to allow it to convey what is commonly called "connected identity" information (the identity of the connected user) in either direction within the context of an existing INVITE-initiated dialog. It can be used to convey:

このドキュメントは、From Headerフィールドの使用を拡張して、既存の招待されたダイアログのコンテキスト内で、一般的に「接続されたアイデンティティ」情報（接続されたユーザーのID）をいずれかの方向に伝えることができるようにします。伝えるために使用できます。

o the callee identity to a caller when a call is answered;

o 通話に応答したときの発信者へのCalleeの身元。

o the identity of a potential callee prior to answer; or

o 回答前の潜在的なカリーの身元。また

o the identity of a user that replaces the caller or callee following a call rearrangement such as call transfer carried out within the PSTN or within a back-to-back user agent (B2BUA) using third party call control techniques.

o PSTN内またはサードパーティのコールコントロール手法を使用して、PSTN内または連続したユーザーエージェント（B2BUA）内で実行されるコール転送などのコール再配置後に発信者またはCalleeを置き換えるユーザーの身元。

Note that the use of standard SIP call transfer techniques, involving the REFER method, leads to the establishment of a new dialog and hence normal mechanisms for caller and callee identity apply.

参照方法を含む標準のSIPコール転送手法の使用は、新しいダイアログの確立につながるため、発信者とCallee IDの通常のメカニズムが適用されることに注意してください。

The provision of the identity of the responder in a response (commonly called "response identity") is outside the scope of this document.

応答におけるレスポンダーの身元の提供（一般に「応答ID」と呼ばれる）は、このドキュメントの範囲外です。

Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS. Providing identity in a separate request allows normal authentication techniques to be used.

アイデンティティが何らかの形で応答して伝えられたとしても、一般にUASを認証するのが難しいことに注意してください。個別のリクエストでIDを提供することで、通常の認証手法を使用できます。

2. Terminology

2. 用語

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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [2]に記載されているように解釈される。

This specification defines the following additional terms:

この仕様では、次の追加用語を定義します。

caller: the user of the UA that issues an INVITE request to initiate a call.

発信者：招待リクエストを発行するUAのユーザー。

caller identity: the identity (Address of Record) of a caller.

発信者のアイデンティティ：発信者の身元（記録のアドレス）。

callee: the user of the UA that answers a call by issuing a 2xx response to an INVITE request.

Callee：招待状リクエストに2xxの応答を発行することにより、電話に応答するUAのユーザー。

callee identity: the identity (Address of Record) of a callee.

Calleeのアイデンティティ：Calleeのアイデンティティ（記録のアドレス）。

potential callee: the user of any UA to which an INVITE request is targeted resulting in formation of an early dialog, but because of parallel or serial forking of the request, not necessarily the user that answers the call.

潜在的なCallee：招待リクエストがターゲットにされているUAのユーザーは、早期のダイアログの形成をもたらしますが、要求の並列またはシリアルフォーキングのために、必ずしも通話に応答するユーザーではありません。

connected user: any user involved in an established call, including the caller, the callee or any user that replaces the caller or callee following a call re-arrangement such as call transfer.

接続されたユーザー：コールの再配置後に呼び出しの再配置後に発信者またはCalleeを交換する、発信者、Callee、またはCalleeを交換するユーザーを含む、確立されたコールに関与するユーザー。

connected identity: the identity (Address of Record) of a connected user.

接続されたアイデンティティ：接続されたユーザーのID（記録アドレス）。

3. Overview of Solution

3. ソリューションの概要

A mid-dialog request is used to provide connected identity. The User Agent Client (UAC) for that request inserts its identity in the From header field of the request. To provide authentication, the Identity header field (RFC 4474 [3]) is inserted by a suitable Authentication Service on the path of the mid-dialog request. Unless provided at the UAC, the Authentication Service is expected to be at a proxy that record routes and is able to authenticate the UAC.

Mid-Dialogリクエストは、接続されたアイデンティティを提供するために使用されます。そのリクエストのユーザーエージェントクライアント（UAC）は、リクエストのヘッダーフィールドにIDを挿入します。認証を提供するために、IDヘッダーフィールド（RFC 4474 [3]）が、Mid-Dialogリクエストのパスで適切な認証サービスによって挿入されます。UACで提供されない限り、認証サービスはルートを記録し、UACを認証できるプロキシになると予想されます。

A request in the opposite direction to the INVITE request prior to or at the time the call is answered can indicate the identity of the potential callee or callee respectively. A request in the same direction as the INVITE request prior to answer can indicate a change of caller. A request in either direction after answering can indicate a change of the connected user. In all cases, a dialog (early or confirmed) has to be established before such a request can be sent.

通話が回答された前または時点で、招待リクエストの反対方向にリクエストは、それぞれ潜在的なCalleeまたはCalleeの身元を示すことができます。回答前の招待要求と同じ方向のリクエストは、発信者の変更を示すことができます。回答後のどちらの方向にもリクエストは、接続されたユーザーの変更を示すことができます。すべての場合において、そのようなリクエストを送信する前に、ダイアログ（早期または確認）を確立する必要があります。

This solution uses the UPDATE method (RFC 3311 [4]) for the request, or in some circumstances the re-INVITE method. To send the callee identity, the UAS for the INVITE request sends the UPDATE request after sending the 2xx response to the INVITE request and after receiving an ACK request. To send the potential callee identity, RFC 3262 [5] is expected to be supported. In this case, the UAS for the INVITE request sends the UPDATE request after receiving and responding to a PRACK request (which occurs after sending a reliable 1xx response to the INVITE request). The UPDATE request could conceivably be used for other purposes too, e.g., it could be used during an early dialog to send the potential callee identity at the same time as a Session Description Protocol (SDP) offer for early media. To indicate a connected identity change during an established call, either the UPDATE method or the re-INVITE method can be used. The re-INVITE method would be used if required for other purposes (e.g., when a B2BUA performs transfer using Third Party Call Control (3PCC) techniques it has to issue a re-INVITE request without an SDP offer to solicit an SDP offer from the UA).

このソリューションでは、リクエストに更新方法（RFC 3311 [4]）を使用するか、状況によっては再入札法を使用します。CalleeのIDを送信するには、招待リクエストのUASは、招待リクエストに2xx応答を送信した後、ACKリクエストを受信した後に更新リクエストを送信します。潜在的なCalleeのアイデンティティを送信するために、RFC 3262 [5]がサポートされると予想されます。この場合、招待リクエストのUASは、プラックリクエストを受信して応答した後に更新リクエストを送信します（これは、招待リクエストに信頼できる1XX応答を送信した後に発生します）。更新リクエストは、他の目的にも使用される可能性があります。たとえば、初期のダイアログで使用して、初期メディア向けのセッション説明プロトコル（SDP）のオファーと同時に潜在的なCallee IDを送信することができます。確立された呼び出し中に接続されたアイデンティティの変更を示すために、更新方法またはREインバイトメソッドのいずれかを使用できます。他の目的に必要な場合は、re inviteメソッドが使用されます（たとえば、B2BUAがサードパーティのコールコントロール（3PCC）手法を使用して転送を実行する場合、SDPオファーなしでSDPオファーなしで再インバイトリクエストを発行する必要があります。ua）。

This solution involves changing the URI (not the tags) in the To and From header fields of mid-dialog requests and their responses, compared with the corresponding values in the dialog forming request and response. Changing the To and From header field URIs was contemplated in Section 12.2.1.1 of RFC 3261 [1], which says:

このソリューションでは、ダイアログフォームのリクエストと応答の対応する値と比較して、ミッドダイアログ要求のヘッダーフィールドとその応答のヘッダーフィールドとその応答のURI（タグではなく）を変更することが含まれます。ヘッダーフィールドのURISを変更することは、RFC 3261 [1]のセクション12.2.1.1で検討されていました。

"Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543 [6], which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification."

「後続のリクエスト内の元のリクエストのフィールドからのURIの使用は、ダイアログ識別にURIを使用したRFC 2543 [6]との逆方向の互換性のために行われます。この仕様では、ダイアログ識別にはタグのみが使用されます。。ミッドダイアログリクエストにおけるURIとのオリジナルの往復の必須の反映は、この仕様のその後の改訂で非推奨になると予想されます。」

This document therefore deprecates mandatory reflection of the original To and From URIs in mid-dialog requests and their responses, which constitutes a change to RFC 3261 [1]. This document makes no provision for proxies that are unable to tolerate a change of URI, since changing the URI has been expected for a considerable time. To cater for any UAs that are not able to tolerate a change of URI, a new option tag "from-change" is introduced for providing a positive indication of support in the Supported header field. By sending a request with a changed From header field URI only to targets that have indicated support for this option, there is no need to send this option tag in a Require header field.

したがって、このドキュメントは、Mid-Dialog要求におけるURISとの往復とその応答の往復の必須の反映を非難します。これは、RFC 3261 [1]の変更を構成します。このドキュメントは、URIの変更がかなりの時間が予想されているため、URIの変更に耐えられないプロキシを規定していません。URIの変更に耐えられないUASに対応するために、サポートされているヘッダーフィールドでのサポートの肯定的な兆候を提供するために、新しいオプションタグ「From-change」が導入されています。HeaderフィールドURIからのみ変更されたリクエストを送信することにより、このオプションのサポートを示すターゲットにのみ変更することにより、このオプションタグを要求ヘッダーフィールドに送信する必要はありません。

In addition to allowing the From header field URI to change during a dialog to reflect the connected identity, this document also requires a UA that has received a connected identity in the URI of the From header field of a mid-dialog request to use that URI in the To header field of any subsequent mid-dialog request sent by that UA.

接続されたアイデンティティを反映するダイアログ中にHeaderフィールドURIが変更できるようにすることに加えて、このドキュメントでは、そのURIを使用するためのミッドダイアログ要求のヘッダーフィールドのURIで接続されたアイデンティティを受信したUAも必要です。そのUAによって送信されたその後のミッドダイアログリクエストのヘッダーフィールドへ。

In the absence of a suitable Authentication Service on the path of the mid-dialog request, the UAS will receive an unauthenticated connected identity (i.e., without a corresponding Identity header field). The implications of this are discussed in Section 7

Mid-Dialogリクエストのパスに適切な認証サービスがない場合、UASは認証されていない接続されたIDを受け取ります（つまり、対応するIDヘッダーフィールドなし）。これの意味については、セクション7で説明します

4. Behaviour

4. 行動

4.1. Behaviour of a UA that Issues an INVITE Request Outside the Context of an Existing Dialog

4.1. 既存のダイアログのコンテキスト外で招待リクエストを発行するUAの動作

When issuing an INVITE request, a UA compliant with this specification MUST include the "from-change" option tag in the Supported header field.

招待リクエストを発行する場合、この仕様に準拠したUAには、サポートされているヘッダーフィールドに「変更」オプションタグを含める必要があります。

Note that sending the "from-change" option tag does not guarantee that connected identity will be received in subsequent requests.

「変更」オプションタグを送信しても、後続のリクエストで接続されたIDが受信されることを保証しないことに注意してください。

4.2. Behaviour of a UA that Receives an INVITE Request outside the Context of an Existing Dialog

4.2. 既存のダイアログのコンテキストの外で招待リクエストを受け取るUAの動作

After receiving an INVITE request, a UA compliant with this specification MUST include the "from-change" option tag in the Supported header field of any dialog-forming response.

招待リクエストを受信した後、この仕様に準拠したUAには、ダイアログ形成応答のサポートされているヘッダーフィールドに「変更」オプションタグを含める必要があります。

Note that sending the "from-change" option tag does not guarantee that connected identity will be received in the event of a change of caller.

「変更」オプションタグを送信しても、発信者が変更された場合に接続されたIDが受信されることを保証しないことに注意してください。

After an early dialog has been formed, if the "from-change" option tag has been received in a Supported header field, the UA MAY issue an UPDATE request (RFC 3311 [4]) on the same dialog, subject to having sent a reliable provisional response to the INVITE request and having received and responded to a PRACK request. After a full dialog has been formed (after sending a 2xx final response to the INVITE request), if the "from-change" option tag has been received in a Supported header field and an UPDATE request has not already been sent on the early dialog, the UA MUST issue an UPDATE request on the same dialog. In either case, the UPDATE request MUST contain the callee's (or potential callee's) identity in the URI of the From header field (or an anonymous identity if anonymity is required).

早期のダイアログが形成された後、サポートされているヘッダーフィールドで「変更」オプションタグが受信された場合、UAは同じダイアログに更新リクエスト（RFC 3311 [4]）を発行する場合があります。招待リクエストに対する信頼できる暫定的な対応と、プラックリクエストに受け取って応答しました。完全なダイアログが形成された後（招待リクエストに2xx最終応答を送信した後）、サポートされているヘッダーフィールドで「変更」オプションタグが受信され、早期ダイアログで更新リクエストがまだ送信されていない場合、UAは、同じダイアログで更新リクエストを発行する必要があります。どちらの場合でも、更新要求には、From HeaderフィールドのURIにCallee（または潜在的なCalleeの）アイデンティティが含まれている必要があります（または匿名が必要な場合は匿名のID）。

Note that even if the URI does not differ from that in the To header field URI of the INVITE request, sending a new request allows the Authentication Service to assert authentication of this identity and confirms to the peer UA that the connected identity is the same as that in the To header field URI of the INVITE request.

URIがInviteリクエストのヘッダーフィールドURIのそれと変わらない場合でも、新しいリクエストを送信することで、認証サービスがこのIDの認証を主張し、接続されたアイデンティティが同じであることをピアUAに確認できることに注意してください。招待リクエストのヘッダーフィールドURIへ。

4.3. Behaviour of a UA Whose Identity Changes during an Established INVITE-initiated Dialog

4.3. 確立された招待されたダイアログ中にアイデンティティが変化するUAの動作

If the "from-change" option tag has been received in a Supported header field during an INVITE-initiated dialog and if the identity associated with the UA changes (e.g., due to transfer) compared to the last identity indicated in the From header field of a request sent by that UA, the UA MUST issue a request on the same dialog containing the new identity in the URI of the From header field (or an anonymous identity if anonymity is required). For this purpose the UA MUST use the UPDATE method unless for other reasons the re-INVITE method is being used at the same time.

招待されたダイアログ中に「変更された」オプションタグがサポートされているヘッダーフィールドで受信された場合、およびFrom Headerフィールドに示された最後のIDと比較して、UAに関連付けられたIDが変更された場合（たとえば、転送に起因する）そのUAから送信されたリクエストのうち、UAは、HeaderフィールドのURIに新しいIDを含む同じダイアログにリクエストを発行する必要があります（または匿名が必要な場合は匿名のID）。この目的のために、UAは、他の理由で再入札法が同時に使用されている場合を除き、更新方法を使用する必要があります。

4.4. General UA Behaviour

4.4. 一般的なUA行動

4.4.1. Sending a Mid-Dialog Request

4.4.1. ミッドダイアログリクエストの送信

When sending a mid-dialog request, a UA MUST observe the requirements of RFC 4474 [3] when populating the From header field URI, including provisions for achieving anonymity.

ミッドダイアログリクエストを送信するとき、UAは、匿名性を達成するための規定を含む、ヘッダーフィールドURIから住むときにRFC 4474 [3]の要件を遵守する必要があります。

This will allow an Authentication Service on the path of the mid-dialog request to insert an Identity header field.

これにより、Mid-Dialogリクエストのパス上の認証サービスがIDヘッダーフィールドを挿入することができます。

When sending a mid-dialog request, a UA MUST populate the To header field URI with the current value of the remote URI for that dialog, where this is subject to update in accordance with the rules of Section 4.4.2 of this document rather than being fixed at the beginning of the dialog in accordance with RFC 3261 [1].

ミッドダイアログリクエストを送信する場合、UAはそのダイアログのリモートURIの現在の値をヘッダーフィールドURIに入力する必要があります。これは、このドキュメントのセクション4.4.2のルールではなく、更新される場合があります。RFC 3261 [1]に従ってダイアログの先頭に固定されています。

After sending a request with a revised From header field URI (i.e., revised compared to the URI sent in the From header field of the previous request on this dialog or in the To header field of the received dialog-forming INVITE request if no request has been sent), the UA MUST send the same URI in the From header field of any future requests on the same dialog, unless the identity changes again. Also, the UA MUST be prepared to receive the revised URI in the To header field of subsequent mid-dialog requests and MUST also continue to be prepared to receive the old URI at least until a request containing the revised URI in the To header field has been received.

ヘッダーフィールドURIから改訂されたリクエストを送信した後（つまり、このダイアログの前のリクエストのヘッダーフィールドから送信されたURIと比較して、またはリクエストがない場合は受信したダイアログ形成招待リクエストのヘッダーフィールドに送信されたURIと比較して改訂されました送信）、UAは、アイデンティティが再び変更されない限り、同じダイアログの将来のリクエストのヘッダーフィールドに同じURIを送信する必要があります。また、UAは、後続の中間リクエストのヘッダーへのフィールドで改訂されたURIを受信する準備をしなければならず、少なくともヘッダーフィールドに改訂されたURIを含むリクエストがあるまで、少なくとも古いURIを受け取る準備をし続けなければなりません受け取られました。

The mid-dialog request can be rejected in accordance with RFC 4474 [3] if the UAS does not accept the connected identity. If the UAC receives a 428, 436, 437, or 438 response to a mid-dialog request it SHOULD regard the dialog as terminated in the case of a dialog- terminating request and SHOULD take no action in the case of any other request.

UASが接続されたアイデンティティを受け入れない場合、RFC 4474 [3]に従って、中間のリクエストを拒否できます。UACが428、436、437、または438のMid-Dialogリクエストに対する応答を受信した場合、ダイアログリクエストの場合にダイアログを終了し、他のリクエストの場合には措置を講じてはなりません。

Any attempt to repeat the request or send any other mid-dialog request is likely to result in the same response, since the UA has no control over actions of the Authentication Service.

UAが認証サービスのアクションを制御できないため、リクエストを繰り返したり、他のMid-Dialogリクエストを送信しようとすると、同じ応答が発生する可能性があります。

4.4.2. Receiving a Mid-Dialog Request

4.4.2. ミッドダイアログリクエストを受信します

If a UA receives a mid-dialog request from the peer UA, the UA can make use of the identity in the From header field URI (e.g., by indicating to the user). The UA MAY discriminate between signed and unsigned identities. In the case of a signed identity, the UA SHOULD invoke a Verifier (see Section 4.6) if it cannot rely on the presence of a Verifier on the path of the request.

UAがピアUAからミッドダイアログリクエストを受信した場合、UAはFrom HeaderフィールドURIのIDを利用できます（たとえば、ユーザーに示すことにより）。UAは、署名されたアイデンティティと署名されていないアイデンティティを区別する場合があります。署名された身元の場合、UAは、リクエストのパス上の検証剤の存在に依存できない場合は、Verifier（セクション4.6を参照）を呼び出す必要があります。

If a UA receives a mid-dialog request from the peer UA in which the From header field URI differs from that received in the previous request on that dialog or that sent in the To header field of the original INVITE request and if the UA sends a 2xx response, the UA MUST update the remote URI for this dialog, as defined in RFC 3261 [1]. This will cause the new value to be used in the To header field of subsequent requests that the UA sends, in accordance with the rules of Section 4.4.1. If any other final response is sent the UA MUST NOT update the remote URI for this dialog.

UAがピアUAからミッドダイアログのリクエストを受け取った場合、そのダイアログの前のリクエストでヘッダーフィールドURIが受信したものとは異なる場合、または元の招待リクエストのヘッダーフィールドに送信されたものと、UAが送信する場合2XX応答、UAは、RFC 3261 [1]で定義されているように、このダイアログのリモートURIを更新する必要があります。これにより、セクション4.4.1の規則に従って、UAが送信する後続の要求のヘッダーフィールドで新しい値が使用されます。他の最終応答が送信された場合、UAはこのダイアログのリモートURIを更新してはなりません。

4.5. Authentication Service Behaviour

4.5. 認証サービスの動作

An Authentication Service MUST behave in accordance with RFC 4474 [3] when dealing with mid-dialog requests.

認証サービスは、Mid-Dialogリクエストを処理する際にRFC 4474 [3]に従って動作する必要があります。

Note that RFC 4474 is silent on how to behave if the identity in the From header field is not one that the UAC is allowed to assert, and therefore it is a matter for local policy whether to reject the request or forward it without an Identity header field. Policy can be different for a mid-dialog request compared with other requests.

RFC 4474は、From HeaderフィールドのIDがUACが主張することを許可されているものではない場合に振る舞う方法について沈黙していることに注意してください。分野。ポリシーは、他のリクエストと比較して、ミッドダイアログリクエストの場合は異なる場合があります。

Note that when UAs conform with this specification the Authentication Service should (subject to the normal rules for authentication) be able to authenticate the sender of a request as being the entity identified in the From header field and hence will be able provide a signature for this identity. This is in contrast to UAs that do not support this specification, where retargeting and mid-dialog identity changes can render the From header field inaccurate as a means of identifying the sender of the request.

UASがこの仕様に準拠する場合、認証サービスは（認証のための通常のルールの対象となります）が、リクエストの送信者をFrom Headerフィールドで特定されたエンティティとして認証できるため、これに署名を提供できることに注意してください。身元。これは、この仕様をサポートしていないUASとは対照的です。この仕様は、リクエストの送信者を識別する手段として、リターゲティングおよびダイアログのIDの変更がヘッダーフィールドを不正確にする可能性があります。

4.6. Verifier Behaviour

4.6. 検証剤の動作

When dealing with mid-dialog requests, an Authentication Service MUST behave in accordance with RFC 4474 [3] updated as stated below.

Mid-Dialogリクエストを処理する場合、認証サービスは、以下に記載されているように更新されたRFC 4474 [3]に従って動作する必要があります。

RFC 4474 [3] states that it is a matter of policy whether to reject a request with a 428 (Use Identity Header) response if there is no Identity header field in the request. A UA MAY adopt a different policy for mid-dialog requests compared with other requests.

RFC 4474 [3]は、リクエストにIDヘッダーフィールドがない場合、428（IDヘッダーを使用）応答でリクエストを拒否するかどうかはポリシーの問題であると述べています。UAは、他のリクエストと比較して、Mid-Dialog要求のために異なるポリシーを採用する場合があります。

4.7. Proxy Behaviour

4.7. プロキシの動作

A proxy that receives a mid-dialog request MUST be prepared for the To header field URI and/or the From header field URI to differ from those that appeared in the dialog-forming request and response.

ミッドダイアログリクエストを受信するプロキシは、ダイアログ形成リクエストと応答に表示されたものと異なるために、ヘッダーフィールドURIおよび/またはFrom HeaderフィールドURIのために準備する必要があります。

A proxy that is able to provide an Authentication Service for mid-dialog requests MUST record route if Supported: from-change is indicated in the dialog forming request received by the proxy from the UAC.

Mid-Dialogリクエストに認証サービスを提供できるプロキシは、サポートされている場合、ルートを記録する必要があります。

5. Examples

5. 例

In the examples below, several messages contain unfolded lines longer than 72 characters. These are captured between tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line-feeds or carriage returns).

以下の例では、いくつかのメッセージには72文字を超える展開された行が含まれています。これらはタグ間でキャプチャされます。単一の展開ラインは、タグ間に表示されるすべての線を直接連結することにより再構築されます（ラインフィードまたはキャリッジリターンを破棄します）。

In the examples, the domain example.com is assumed to have the following private key (rendered in PEM format). The private key is used by the Authentication Service for generating the signature in the Identity header field.

例では、Domain Example.comには、次の秘密鍵があると想定されています（PEM形式でレンダリング）。秘密鍵は、アイデンティティヘッダーフィールドに署名を生成するために認証サービスによって使用されます。

5.1. Sending Connected Identity after Answering a Call

5.1. 電話に応答した後に接続されたIDを送信します

In this example, Carol's UA has been reached by retargeting at the proxy and thus her identity (AoR) is not equal to that in the To header field of the received INVITE request (Bob). Carol's UA conveys Carol's identity in the From header field of an UPDATE request. The proxy also provides an Authentication Service and therefore adds Identity and Identity-Info header fields to the UPDATE request.

この例では、キャロルのUAはプロキシでのリターゲティングによって到達しました。したがって、彼女のアイデンティティ（AOR）は、受信した招待リクエスト（BOB）のヘッダーからヘッダーフィールドのそれに等しくありません。キャロルのUAは、更新リクエストのヘッダーフィールドでキャロルのアイデンティティを伝えます。プロキシは認証サービスも提供するため、IDとINFOのヘッダーフィールドを更新リクエストに追加します。

Alice's UA PROXY + Carol's UA Authentication Service

アリスのUAプロキシキャロルのUA認証サービス

      INVITE(1)            INVITE(2)
  ---------------->   ---------------->

       200(4)                200(3)
  <----------------   <----------------

       ACK(5)                ACK(6)
  ---------------->   ---------------->

      UPDATE(8)            UPDATE(7)
  <----------------   <----------------

       200(9)                200(10)
  ---------------->   ---------------->

INVITE (1):

招待（1）：

INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000INVITE (2):

V = 0 O = USERA 2890844526 2890844526 IN IP4 UA1.EXAMPLE.COM S = SESSION SDP C = IN IP4 UA1.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000000000000000000招待（2）：

INVITE sip:Carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Record-Route: <sip:proxy.example.com;lr>
<allOneLine>
Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1
3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT
p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc="
</allOneLine>
Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 154

v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000200 (3):

V = 0 O = USERA 2890844526 2890844526 IN IP4 UA1.EXAMPLE.COM S = SESSION SDP C = IN IP4 UA1.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000000000000000000200（3）：

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
<allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154

v=0 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com s=Session SDP c=IN IP4 ua2.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

v = 0 o = userb 2890844536 2890844536 in ip4 ua2.example.com s = session sdp c = in ip4 ua2.example.com t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000000000000000000

200 (4):

200（4）：

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (5):

ACK（5）：

ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:proxy.example.com;lr>
Content-Length: 0

ACK (6):

ACK（6）：

ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.
1
</allOneLine>
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 69
Content-Length: 0

UPDATE (7):

更新（7）：

UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Route: <sip:proxy.example.com;lr>
Contact: <sip:Carol@ua2.example.com>
Content-Length: 0

Note that the URI in the From header field differs from that in the To header field in the INVITE request/response. However, the tag is the same as that in the INVITE response.

From HeaderフィールドのURIは、Invite Request/ResponseのTo HeaderフィールドのURIとは異なることに注意してください。ただし、タグは招待対応のタグと同じです。

UPDATE (8):

更新（8）：

UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:15 GMT
Contact: <sip:Carol@ua2.example.com>
<allOneLine>
Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t
ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9
KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (9):

200（9）：

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
200 (10):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

5.2. Sending Revised Connected Identity during a Call

5.2. 電話中に改訂された接続されたIDを送信します

In this example, a call is established between Alice and Bob, where Bob (not shown) lies behind a B2BUA. Bob's identity is conveyed by an UPDATE request. Then the B2BUA executes call transfer using third party call control (3PCC) techniques as described in RFC 3725 [7] (e.g., under the control of a click-to-dial application). As a result, Alice becomes connected to Carol (also not shown), and a re-INVITE request is issued allowing the session to be renegotiated. The B2BUA provides the Authentication Service and thus generates the Identity header field in the re-INVITE request to provide authentication of Carol's identity.

この例では、アリスとボブの間に呼び出しが確立され、ボブ（表示なし）はB2BUAの後ろにあります。ボブの身元は、更新リクエストによって伝えられます。次に、B2BUAは、RFC 3725 [7]（たとえば、クリックツーダイアルアプリケーションの制御下）で説明されているように、サードパーティコールコントロール（3PCC）手法を使用してコール転送を実行します。その結果、アリスはキャロルに接続され（示されていません）、セッションを再交渉できるようにする再入力要求が発行されます。B2BUAは認証サービスを提供するため、CarolのIDの認証を提供するために、Re-InviteリクエストでIDヘッダーフィールドを生成します。

Alice's UA B2BUA

アリスのua b2bua

      INVITE(1)
  ---------------->

       200(2)
  <----------------

       ACK(3)
  ---------------->

      UPDATE(4)
  <----------------

       200(5)
  ---------------->

    re-INVITE(6)
  <----------------

       200(7)
  ---------------->

       ACK(8)
  <---------------

INVITE (1):

招待（1）：

INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

200 (2)

200（2）

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:xyz@b2bua.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com s=Session SDP c=IN IP4 ua2.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

v = 0 o = userb 2890844536 2890844536 in ip4 ua2.example.com s = session sdp c = in ip4 ua2.example.com t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000000000000000000

ACK (3)

ACK（3）

ACK sip:xyz@b2bua.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
UPDATE (4)

UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:12 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO
UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c
D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (5)

200（5）

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.
2.2
</allOneLine>
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
re-INVITE (6)

INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:03:20 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp
al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U
3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (7)

200（7）

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.
2.2
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 154

v=0 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com s=Session SDP c=IN IP4 ua1.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000ACK (8)

V = 0 O = USERA 2890844526 2890844526 IN IP4 UA1.EXAMPLE.COM S = SESSION SDP C = IN IP4 UA1.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000000000000000000ACK（8）

ACK sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 ACK
Max-Forwards: 70
Content-Length: 154

v=0 o=UserC 2890844546 2890844546 IN IP4 ua3.example.com s=Session SDP c=IN IP4 ua3.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

V = 0 O = USERC 2890844546 2890844546 in ip4 ua3.example.com s = session sdp c = in ip4 ua3.example.com t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000

6. IANA Considerations

6. IANAの考慮事項

This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261 [1].

この仕様は、RFC 3261 [1]のセクション27.1のガイドラインに従って、新しいSIPオプションタグを登録します。

This document defines the SIP option tag "from-change".

このドキュメントでは、SIPオプションタグ「From-Change」を定義します。

The following row has been added to the "Option Tags" section of the SIP Parameter Registry:

次の行は、SIPパラメーターレジストリの「オプションタグ」セクションに追加されました。

   +------------+------------------------------------------+-----------+
   | Name       | Description                              | Reference |
   +------------+------------------------------------------+-----------+
   | from-change| This option tag is used to indicate that | [RFC4916] |
   |            | a UA supports changes to URIs in From    |           |
   |            | and To header fields during a dialog.    |           |
   +------------+------------------------------------------+-----------+

7. Security considerations

7. セキュリティに関する考慮事項

RFC 4474 [3] discusses security considerations relating to the Identity header field in some detail. Those same considerations apply when using the Identity header field to authenticate a connected identity in the From header field URI of a mid-dialog request.

RFC 4474 [3]は、IDヘッダーフィールドに関連するセキュリティに関する考慮事項について、ある程度詳細に説明しています。これらの同じ考慮事項は、IDヘッダーフィールドを使用して、ミッドダイアログリクエストのヘッダーフィールドURIに接続されたアイデンティティを認証する場合に適用されます。

A received From header field URI in a mid-dialog request for which no valid Identity header field (or other means of authentication) has been received either in this request or in an earlier request on this dialog cannot be trusted (except in very closed environments) and is expected to be treated in a similar way to a From header field in a dialog-initiating request that is not backed up by a valid Identity header field. However, it is recommended not to reject a mid-dialog request on the grounds that the Identity header field is missing (since this would interfere with ongoing operation of the call). The absence of a valid Identity header field can influence the information given to the user. A UA can clear the call if policy or user preference dictates.

有効なアイデンティティヘッダーフィールド（または他の認証手段）がこのリクエストまたはこのダイアログの以前のリクエストで受信されていないミッドダイアログリクエストでヘッダーフィールドURIから受け取ったことは、非常に閉じた環境を除き、信頼できません。）そして、有効なIDヘッダーフィールドによってバックアップされていないダイアログ開示要求で、ヘッダーフィールドと同様の方法で扱われることが期待されています。ただし、アイデンティティヘッダーフィールドが欠落しているという理由で、ミッドダイアログリクエストを拒否しないことをお勧めします（これにより、コールの継続的な操作が妨げられるため）。有効なIDヘッダーフィールドがないことは、ユーザーに与えられた情報に影響を与える可能性があります。UAは、ポリシーまたはユーザーの好みが指示されている場合に通話をクリアできます。

A signed connected identity in a mid-dialog request (URI in the From header field accompanied by a valid Identity header field) provides information about the peer UA in a dialog. In the case of the UA that was the UAS in the dialog-forming request, this identity is not necessarily the same as that in the To header field of the dialog-forming request. This is because of retargeting during the routing of the dialog-forming request. A signed connected identity says nothing about the legitimacy of such retargeting, but merely reflects the result of that retargeting. History information (RFC 4244 [8]) can provide additional hints as to how the connected user has been reached.

ミッドダイアログリクエストで署名された接続されたアイデンティティ（有効なアイデンティティヘッダーフィールドを伴うヘッダーフィールドのURI）は、ダイアログ内のピアUAに関する情報を提供します。ダイアログ形成リクエストのUAであったUAの場合、このアイデンティティは、ダイアログ形成リクエストのヘッダーフィールドのフィールドと必ずしも同じではありません。これは、ダイアログ形成リクエストのルーティング中のリターゲティングによるものです。署名された接続されたアイデンティティは、そのようなリターゲティングの正当性については何も述べていませんが、そのリターゲティングの結果を単に反映しています。履歴情報（RFC 4244 [8]）は、接続されたユーザーにどのように到達したかに関する追加のヒントを提供できます。

Likewise, when a signed connected identity indicates a change of identity during a dialog, it conveys no information about the reason for such a change of identity or its legitimacy.

同様に、署名された接続されたアイデンティティがダイアログ中にアイデンティティの変化を示した場合、そのようなアイデンティティの変更またはその正当性の理由についての情報は伝えません。

Use of the sips URI scheme can minimize the chances of attacks in which inappropriate connected identity information is sent, either at call establishment time or during a call.

SIPS URIスキームの使用は、コール設定時または通話中に、不適切な接続されたID情報が送信される攻撃の可能性を最小限に抑えることができます。

Anonymity can be required by the user of a connected UA. For anonymity the UA is expected to populate the URI in the From header field of a mid-dialog request in the way described in RFC 4474 [3].

匿名性は、接続されたUAのユーザーが必要とすることができます。匿名性のために、UAは、RFC 4474 [3]に記載されている方法で、ミッドダイアログ要求のヘッダーフィールドにURIを埋めることが期待されています。

8. Acknowledgments

8. 謝辞

Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani, Cullen Jennings, Paul Kyzivat, Hans Persson, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, Shida Schubert, Ya-Ching Tan, and Dan Wing for providing valuable comments.

フランソワ・オーデット、フランク・デルクス、ステフェン・フライス、ヴィジェイ・ガルバニ、カレン・ジェニングス、ポール・キジバット、ハンス・ペルソン、ジョン・ピーターソン、エリック・レスコルラ、ジョナサン・ローゼンバーグ、シダ・シューベルト、ヤ・チング・タン、ダン・ウィング

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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 INIATIATION 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] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.

[3] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。

[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.

[4] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年9月。

[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002.

[5] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。

9.2. Informative References

9.2. 参考引用

[6] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.

[6] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。

[7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC 3725, June 2002.

[7] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2002年6月、RFC 3725。

[8] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.

[8] Barnes、M。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。

Author's Address

著者の連絡先

John Elwell Siemens Enterprise Communications Limited Technology Drive Beeston, Nottingham NG9 1LA UK

ジョンエルウェルシーメンスエンタープライズコミュニケーションリミテッドテクノロジードライブビーストン、ノッティンガムNG9 1LA UK

   Phone: +44 115 943 4989
   EMail: john.elwell@siemens.com

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（2007）。

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, THE IETF TRUST 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、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エディター機能の資金は現在、インターネット協会によって提供されています。