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

URL : https://tools.ietf.org/html/rfc4916
タイトル : RFC 4916 - セッション開始プロトコルで接続されているアイデンティティ（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)

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）IETFトラスト（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).

この文書では、逆方向の要求によってピアUAにその識別情報を供給するためのダイアログ形成要求を受信したセッション開始プロトコル（SIP）ユーザエージェント（UA）のための手段を提供し、その識別のために署名します認証サービスによって。そのため（のRequest-URIの値を変更）ダイアログ形成要求のターゲット変更のために、それを受け取るUAは、（ユーザエージェントサーバ、UASは）Toヘッダーフィールドとは異なるアイデンティティを持つことができます。同じメカニズムがあるため、公共の場でいくつかのアクションのゲートウェイの背後交換電話網（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によって開始された通信に対処する方法を決定するために、この情報を必要とします。呼び出しに応答する当事者の身元は、着信転送など、さまざまな理由のために、最初の着信側のものとは異なる着信呼分配及びアップを選ぶ呼び出すことができます。いくつかのケースではこれらのIDを公開しない理由があることができますがまた、一度の呼び出しは、など、公園や検索を呼び出し、当事者がそのコール転送などの理由で異なるIDと異なるパーティに置き換えることができ、回答されていますこの情報を提供するためのメカニズムを有することが望ましいです。

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:

この文書では、それは、既存のINVITE-開始ダイアログのコンテキスト内でどちらの方向に一般的に「接続されているアイデンティティ」の情報（接続ユーザーの同一性）と呼ばれているものを伝えることを可能にするFromヘッダーフィールドの使用を拡張します。伝えるために使用することができます。

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

コールが応答され、発信者に呼び出し先のアイデンティティO;

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.

コール転送がPSTN内第三者呼制御技術を使用してバックツーバックユーザエージェント（B2BUA）内で行うようなコール転位次の発呼者または被呼者を置き換えるユーザーのID O。

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.

、方法をREFER含む標準的なSIPコール転送技術の使用は、呼び出し元と呼び出し先のアイデンティティが適用のための新しいダイアログ、したがって、通常のメカニズムの確立につながることに注意してください。

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

（一般に「応答アイデンティティー」と呼ばれる）応答で応答者のアイデンティティの規定は、この文書の範囲外です。

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

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.

呼び出し元：呼び出しを開始するためのINVITEリクエストを発行UAのユーザー。

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

呼び出し元のID：呼び出し側のID（レコードのアドレス）。

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

呼び出し先：INVITEリクエストに対する2xx応答を発行することによって、コールに応答UAのユーザー。

callee identity: the identity (Address of Record) of a 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.

潜在的な呼び出し先：INVITEリクエストをするためにすべての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.

接続されたユーザ：発呼者、被呼者、またはそのようなコール転送などのコールの再構成次の発呼者または被呼者に取って代わる任意のユーザーを含む、確立された呼に関与する任意のユーザー。

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.

半ば対話要求は、接続IDを提供するために使用されます。その要求のユーザエージェントクライアント（UAC）は、リクエストのFromヘッダフィールドにその識別情報を挿入します。認証、（RFC 4474 [3]）中間ダイアログ要求の経路上に適切な認証サービスによって挿入されたアイデンティティ・ヘッダ・フィールドを提供します。 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.

呼び出しの前に、または時にINVITEリクエストとは逆方向に、要求は、それぞれの潜在的被呼者又は被呼者の識別情報を示すことができる回答されます。答える前に、INVITE要求と同じ方向の要求は、呼び出し元の変化を示すことができます。応答後にいずれかの方向における要求は、接続されたユーザの変化を示すことができます。すべての場合において、ダイアログは（早期または確認された）そのような要求を送信することができます前に確立する必要があります。

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

この溶液は、UPDATEメソッド（RFC 3311 [4]）要求のための、またはいくつかの状況では、再INVITE方法を使用します。呼び出し先のIDを送信するには、INVITEリクエストのUASは、INVITEリクエストへとACK要求を受信した後、2xx応答を送信した後にUPDATE要求を送信します。潜在的な呼び出し先IDを送信するには、RFC 3262は、[5]は、サポートされることが期待されます。この場合、INVITEリクエストのUASは、受信および（INVITEリクエストに対する信頼性の1xx応答を送信した後に発生する）PRACK要求に応答後に更新要求を送信します。 UPDATE要求が考えられるすぎて他の目的に使用することができ、例えば、セッション記述プロトコル（SDP）の早期メディアの提供と同時に、潜在的な呼び出し先のアイデンティティを送信するために、早期のダイアログ中に使用することができます。確立された呼の間に接続されたアイデンティティの変更を示すために、UPDATEメソッドまたは再INVITE方法のいずれかを使用することができます。必要に応じてB2BUAはそれからSDPのオファーを勧誘するSDPのオファーなしに再INVITEリクエストを発行している第三者呼制御（3PCC）技術を使用して転送を行うときに再INVITE方法は、他の目的（例えば、ために使用されるであろう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（ないタグ）を変更することを含みます。変更とヘッダフィールドのURIからは言った、[1] RFC 3261のセクション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を使用するからと後続のリクエスト内の元の要求のフィールドからは、RFC 2543との下位互換性のために行われているURIの「使用[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.

従って、この文書は、[1] RFC 3261への変更を構成し、ダイアログ中のリクエストとその応答の元へとから、URIの必須反射を、非推奨します。この文書では、URIを変更すると、かなりの時間のために期待されているので、URIの変更を容認することはできませんプロキシのための準備を行いません。 URIの変更を容認することはできません任意のユーザーエージェントに対応するため、「からチェンジ」新しいオプションタグがサポートされているヘッダーフィールドでのサポートの正指標を提供するために導入されます。このオプションのみのサポートを示しているターゲットにヘッダフィールドのURIから変更してリクエストを送信することにより、Requireヘッダーフィールドにこのオプションタグを送信する必要はありません。

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.

ヘッダーフィールドURIから接続IDを反映するように、ダイアログ中に変化させることに加えて、この文書はまた、URIそれを使用する中間ダイアログ要求のヘッダフィールドからのURIに接続された識別情報を受信したUAを必要としますそのUAによって送信された後続の中間ダイアログ要求のToヘッダーフィールドです。

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

中間ダイアログ要求の経路上の適切な認証サービスの非存在下では、UAS（すなわち、対応するIdentityヘッダフィールドなしで）認証されていない接続されたアイデンティティを受信します。これの意味は第7節で議論されています

4. Behaviour

4.行動

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

4.1. 既存のダイアログのコンテキスト外INVITE要求を発行UAの挙動

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

INVITEリクエストを発行する場合、この仕様に準拠した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. 既存のダイアログのコンテキスト外でINVITEリクエストを受信する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.

INVITE要求を受信した後、この仕様に準拠したUAは、任意のダイアログ形成応答のSupportedヘッダフィールドに「から変更」オプションタグを含まなければなりません。

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.

「から変更」オプションタグを送ることが接続されているアイデンティティは、発信者の変更があった場合に受信されることを保証するものではないことに注意してください。

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はUPDATE要求を発行することができる（RFC 3311 [4]）が送信した対象と同じダイアログで信頼できる暫定的なINVITE要求に応答して、受信しPRACK要求に応答しました。「から変更」オプションタグがサポートされているヘッダーフィールドで受信され、UPDATE要求がすでに初期のダイアログ上で送信されていない場合、完全なダイアログは、（INVITEリクエストに対する2xxの最終応答を送信した後に）形成された後、UAは、同じダイアログでUPDATE要求を発行しなければなりません。いずれの場合においても、UPDATE要求は、FromヘッダフィールドのURI（または匿名性が要求される場合、匿名アイデンティティ）で被呼者（または潜在的な被呼者）のアイデンティティを含まなければなりません。

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に確認することに注意してくださいそのINVITEリクエストのフィールドURIをToヘッダです。

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

4.3. IDの変更を設立INVITEが開始したダイアログ中の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.

「から変更」オプションタグは、INVITEが開始したダイアログ中およびサポートされているヘッダフィールドに受信されている場合はUAの変化に関連したアイデンティティが（例えば、転送することにより）最後のIDに比べては、Fromヘッダーフィールドで示された場合そのUAによって送られたリクエストの、UAは、FromヘッダーフィールドのURIで新しいアイデンティティ（または匿名性が必要な場合は、匿名のアイデンティティ）を含む同じダイアログ上の要求を発行しなければなりません。他の理由のために再INVITEメソッドが同時に使用されていない限り、この目的のためにUAは、UPDATEメソッドを使用しなければなりません。

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は、RFC 4474の要件を遵守しなければならない[3]匿名性を達成するための規定を含む、ヘッダーフィールドURIからポピュレートします。

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

これは、Identityヘッダーフィールドを挿入するために、ダイアログ中のリクエストのパス上の認証サービスをできるようになります。

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がこの文書のセクション4.4.2の規則に従って更新なくされる可能性があり、そのダイアログのリモートURIの現在の値とフィールドURIをToヘッダー移入する必要があります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（すなわち、このダイアログ上で、または受信ダイアログ形成全く要求が持っていない場合はINVITEリクエストのヘッダーフィールドに以前の要求のヘッダフィールドから送信されたとの要求を送信した後アイデンティティが再び変更されない限り）送信され、UAは、同じダイアログ上の任意の将来のリクエストのFromヘッダーフィールドに同じURIを送らなければなりません。また、UAは、その後、ダイアログ中のリクエストのToヘッダーフィールドに改訂URIを受け取るために準備しなければなりませんし、また、Toヘッダーフィールドに改訂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は、接続されたアイデンティティを受け入れない場合、ダイアログ中のリクエストは、[3] RFC 4474に従って拒否することができます。 UACは428、436、437、または、ダイアログ中の要求に438応答を受信した場合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は、認証サービスの行動を制御できないため、要求を繰り返すか、他の半ば対話要求を送信しようとすると、同じ応答をもたらす可能性があります。

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ヘッダフィールドURIで識別を利用することができます。 UAは、符号付きと符号なしのアイデンティティを区別するかもしれません。それはリクエストのパス上の検証の存在に依存することができない場合に署名されたアイデンティティの場合、UAは（セクション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はURIがUAが送信する場合には、そのダイアログ上の前の要求で受信した、またはそれがINVITEリクエストを元のフィールドをヘッダーに送信され、異なってヘッダーフィールドかられたピアUAから中間対話要求を受信した場合RFC 3261で定義されるよう2XX応答、UAは、このダイアログのリモートURIを更新しなければならない[1]。これは、新しい値はUAは、セクション4.4.1の規則に従って、送信後続の要求のToヘッダーフィールドで使用されるようになります。他の最終応答が送信された場合、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.

認証サービスは、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.

noteからヘッダーフィールドのアイデンティティがUACがアサートする許可されているものではないので、それは要求を拒否するか、アイデンティティヘッダーなしでそれを転送するかどうかをローカルポリシーの問題である場合、そのRFC 4474が動作するようにどのように沈黙していますフィールド。ポリシーは、他の要求と比較して、ダイアログ中のリクエストのために異なる場合があります。

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.

このために署名を提供できるようになり、したがってUAは、この仕様に準拠したときに認証サービス（認証用の通常の規則に従う）がヘッダフィールドから識別されたエンティティであると要求の送信者を認証することができなければならないことに注意してくださいと身元。これは、リターゲットと、ダイアログ中のアイデンティティの変化は、要求の送信者を特定する手段として、不正確なFromヘッダーフィールドをレンダリングすることができ、この仕様をサポートしていないUAのとは対照的です。

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.

半ばダイアログのリクエストを扱う場合、認証サービスは、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]それはIdentityヘッダフィールドは要求に存在しない場合428（使用のIdentityヘッダ）応答で要求を拒否するか、ポリシーの問題であると述べています。 UAは、他の要求と比較して、ダイアログ中のリクエストのために異なるポリシーを採用してもよいです。

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.

中間対話要求を受信したプロキシは、ToヘッダーフィールドURIのために準備されなければならない、および/またはヘッダーフィールド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.

サポートされている場合は、ダイアログ中のリクエストのための認証サービスを提供することができるプロキシは、ルートを記録しなければなりません：から変更UACからプロキシで受信されたダイアログ形成要求に示されています。

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.

実施例では、example.comドメインは、以下の秘密鍵（PEM形式でレンダリング）を有するものとします。秘密鍵は、Identityヘッダフィールドに署名を生成するための認証サービスによって使用されます。

5.1. Sending Connected Identity after Answering a Call

5.1. コールへの応答後に接続アイデンティティを送信

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）は、受信したINVITEリクエスト（ボブ）のフィールドをヘッダにそれと等しくありません。キャロルのUAは、UPDATEリクエストのFromヘッダーフィールドにキャロルのアイデンティティを伝えます。プロキシは、認証サービスを提供し、したがって、UPDATE要求にアイデンティティとIdentity-Infoヘッダフィールドを付加します。

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

アリスのUA PROXY +キャロルの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：

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

SIPのINVITE：Bob@example.com SIP / 2.0経由：SIP / 2.0 / TLS ua1.example.com;ブランチ= z9hG4bKnashds8へ：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.com >;タグは= 13adc987コールID：12345600@ua1.example.comのCSeq：マックス・フォワードを1 INVITE：70日：木、2002年2月21日13時02分03秒GMTが許可：BYE、INVITE、ACK、CANCEL、OPTIONS、 UPDATEサポートされている：からの変更連絡先：<SIP：alice@ua1.example.com>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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

V = 0 0 =ユーザーA 2890844526 2890844526 IN IP4 ua1.example.com S =セッションのSDP C = IN IP4 ua1.example.com T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

INVITE (2):

（2）INVITE：

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

SIPのINVITE：Carol@ua2.example.com SIP / 2.0経由：SIP / 2.0 / TLS proxy.example.com;分岐= z9hG4bK776asdhds <allOneLine>のVia：SIP / 2.0 / TLS ua1.example.com;分岐= z9hG4bKnashds8、受信= 192.0.2。 1 </ allOneLine>に：から：アリス<SIP：alice@example.com>;タグ= 13adc987のCall-ID：ボブ<bob@example.com SIP> 12345600@ua1.example.comのCSeq：MAX-をINVITE 1フォワード：69日：木、2002年2月21日午後01時02分03秒GMT許可：、INVITE ACK、CANCEL、OPTIONS、BYE、UPDATEサポート：からの変更連絡先：<SIP：alice@ua1.example.com>レコード・ルート：<SIP：proxy.example.com; LR> <allOneLine>アイデンティティ： "xN6gCHR6KxGM + nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G + VwY1 3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR / fFGBrpBSjztmfffLT p6SFLxo9XQSVrkm1O4c / 4UrKn2ejRz + 5BULu9n9kWswzKDNjlYlmmc =" </ allOneLine>アイデンティティ情報：<https://example.com/ example.cer>; ALG = RSA-SHA1のContent-Type：アプリケーション/ SDPコンテンツの長さ：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

V = 0 0 =ユーザーA 2890844526 2890844526 IN IP4 ua1.example.com S =セッションのSDP C = IN IP4 ua1.example.com T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

200 (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

SIP / 2.0 200 OK <allOneLine>ビア：SIP / 2.0 / TLS proxy.example.com;ブランチ= z9hG4bK776asdhds; = 192を受け取りました。 0.2.2 </ allOneLine> <allOneLine>のVia：SIP / 2.0 / TLS ua1.example.com;分岐= z9hG4bKnashds8; = 192.0.2を受けました。 1 <allOneLine>から：ボブ<SIP：bob@example.com>;からタグ= 2ge46ab5：アリス<SIP：alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq：1 INVITE許可：INVITE、ACK、CANCEL、OPTIONS、BYE、UPDATEサポート：からの変更連絡先：<SIP：carol@ua2.example.com>レコード・ルート：<SIP：proxy.example.com; LR>のContent-Type ：アプリケーション/ SDPコンテンツの長さ：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 0 =ユーザーB 2890844536 2890844536 IN IP4 ua2.example.com S =セッションのSDP C = IN IP4 ua2.example.com T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

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

SIP / 2.0 200 OK <allOneLine>ビア：SIP / 2.0 / TLS ua1.example.com;ブランチ= z9hG4bKnashds8; = 192.0.2を受けました。 1 </ allOneLine>は：ボブ：;：アリス<SIP bob@example.com>からタグ= 2ge46ab5 <SIP：alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq： 1許可INVITE：CANCEL、ACKをINVITE、OPTIONS、BYE、UPDATEサポート：からの変更連絡先：<SIP：carol@ua2.example.com>レコード・ルート：<SIP：proxy.example.com; LR>のContentタイプ：アプリケーション/ SDPのContent-Length：154 v = 0 0 =ユーザーB 2890844536 2890844536 IN IP4 ua2.example.com S =セッションのSDP C = IN IP4 ua2.example.com T = 0、M =オーディオ49172 RTP / AVP 0 = 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のSIP：carol@ua2.example.com SIP / 2.0経由：SIP / 2.0 / TLS ua1.example.com;ブランチ= z9hG4bKnashds9から：アリス<SIP：Alice@example.com>;タグ= 13adc987へ：ボブ<一口：Bob@example.com>;タグ= 2ge46ab5コールID：12345600@ua1.example.comのCSeq：1 ACK最大フォワード：70ルート<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

ACKをSIP：carol@ua2.example.com SIP / 2.0経由：SIP / 2.0 / TLS proxy.example.com;分岐= z9hG4bK776asdhdt <allOneLine>のVia：SIP / 2.0 / TLS ua1.example.com;分岐= z9hG4bKnashds9と、受信しました= 192.0.2。 1 </ allOneLine>から：アリス<SIP：Alice@example.com>;タグ= 13adc987：をボブ<SIP：Bob@example.com>;タグ= 2ge46ab5のCall-ID：12345600@ua1.example.comのCSeq： 1 ACKマックス・フォワード：69のContent-Length：0

UPDATE (7):

UPDATE（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

UPDATEのSIP：Alice@ua1.example.com SIP / 2.0経由：SIP / 2.0 / TLS ua2.example.com;ブランチ= z9hG4bKnashdt1から：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5へ：アリス<一口：Alice@example.com>;タグは= 13adc987コールID：12345600@ua1.example.comのCSeq：2 UPDATEマックス - フォワード：70日：木、2002年2月21日午後01時02分15秒GMTルート：<SIP：プロキシ.example.comと、LR>連絡先：<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.

UPDATE (8):

UPDATE（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

UPDATEのSIP：Alice@ua1.example.com SIP / 2.0経由：SIP / 2.0 / TLS proxy.example.com;分岐= z9hG4bK776asdhdu <allOneLine>のVia：SIP / 2.0 / TLS ua2.example.com;分岐= z9hG4bKnashdt1、受信= 192.0.2。 3 </ allOneLine>から：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5に：アリス<SIP：Alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq： 2 UPDATEマックス - フォワード：69日：木、2002年2月21日午前13時02分15秒GMT連絡先：<SIP：Carol@ua2.example.com> <allOneLine>アイデンティティ：「g8WJiVEzrbYum + z2lnS3pL + MIhuI439gDiMCHm01fwX5D8Ft5Ib9t ewLfBT9mDOUSn6wkPSWVQfqdMF / QBPkpsIIROIi2sJOYBEMXZpNrhJd8 / uboXMl9 KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko =」</ allOneLine>アイデンティティ情報：<https://example.com/cert>; ALG = RSA-SHA1のContent-Length：0

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

SIP / 2.0 200 OK <allOneLine>ビア：SIP / 2.0 / TLS proxy.example.com;ブランチ= z9hG4bK776asdhdu; = 192を受け取りました。 0.2.2 </ allOneLine> <allOneLine>のVia：SIP / 2.0 / TLS ua2.example.com;分岐= z9hG4bKnashdt1; = 192.0.2を受けました。 3 </ allOneLine>から：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5に：アリス<SIP：Alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq： 2 UPDATE連絡先：<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

SIP / 2.0 200 OK <allOneLine>ビア：SIP / 2.0 / TLS ua2.example.com;ブランチ= z9hG4bKnashdt1; = 192.0.2を受けました。 3 </ allOneLine>から：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5に：アリス<SIP：Alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq： 2 UPDATE連絡先：<SIP：Alice@ua1.example.com>のContent-Length：0

5.2. Sending Revised Connected Identity during a Call

5.2. 通話中に改訂接続アイデンティティを送信

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の背後にあるアリスとボブとの間で確立されます。ボブのアイデンティティは、UPDATE要求によって搬送されます。 [7]（例えば、クリックツーダイヤルアプリケーションの制御下で）RFC 3725に記載されているように、その後B2BUAは、第三者呼制御（3PCC）技術を使用して、コール転送を実行します。結果として、アリスは、キャロル（図示せず）に接続されてなり、再INVITE要求は、セッションを再交渉することを可能に発行されます。 B2BUAは、認証サービスを提供し、従って、キャロルの識別の認証を提供するために再INVITEリクエストのIDヘッダフィールドを生成します。

Alice's UA B2BUA

アリスのIT B2BUA

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

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

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

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

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

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

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

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

INVITE (1):

（1）INVITE：

200 (2)

２００（２）

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 0 =ユーザーB 2890844536 2890844536 IN IP4 ua2.example.com S =セッションのSDP C = IN IP4 ua2.example.com T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

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

ACKのSIP：xyz@b2bua.example.com SIP / 2.0経由：SIP / 2.0 / TLS ua1.example.com;ブランチ= z9hG4bKnashds9から：アリス<SIP：Alice@example.com>;タグ= 13adc987へ：ボブ<一口：Bob@example.com>;タグ= 2ge46ab5コールID：12345600@ua1.example.comのCSeq：1 ACKマックス・フォワード：70のContent-Length：0

UPDATE (4)

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

UPDATEのSIP：alice@ua1.example.com SIP / 2.0経由：SIP / 2.0 / TLS b2bua.example.com;ブランチ= z9hG4bKnashdt1から：ボブ<SIP：Bob@example.com>;タグ= 2ge46ab5へ：アリス<一口：Alice@example.com>;タグは= 13adc987コールID：12345600@ua1.example.comのCSeq：2 UPDATEマックス - フォワード：70日：木、2002年2月21日午後1時02分12秒GMT連絡先：<SIP：XYZ @ b2bua.example.com> <allOneLine>アイデンティティ： "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma + rs8ZOv0 + Z / Q3Z5c D26HrmitU + OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E =" </ allOneLine>アイデンティティ情報：<https://example.com/cert>; ALG = rsa- SHA1のコンテンツの長さ：0

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)

経由SIP / 2.0 200 OK <allOneLine>：SIP / 2.0 / TLS b2bua.example.com;ブランチ= z9hG4bKnashdt1は、受信= 192.0。 2.2 </ allOneLine>から：ボブ<SIP：Bob@example.com>;タグ= 2ge46ab5に：アリス<SIP：Alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq： 2 UPDATE連絡先：<SIP：Alice@ua1.example.com>のContent-Length：0再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

SIP INVITE：alice@ua1.example.comをSIP / 2.0経由：SIP / 2.0 / TLS b2bua.example.com;ブランチ= z9hG4bKnashdxyから：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5へ：アリス<一口：Alice@example.com>;タグは= 13adc987コールID：12345600@ua1.example.comのCSeq：マックス-前方にINVITE 3：70日：木、2002年2月21日午前13時03分20秒GMT連絡先：<SIP：XYZ @ b2bua.example.com> <allOneLine>アイデンティティ： "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr / Mwu7j6Gp al8ckVM2vd1zqH / F4WJXYDlB525uuJm / fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U 3kGg8To / 6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo =" </ allOneLine>アイデンティティ情報：<https://example.com/cert>; ALG = rsa- SHA1のコンテンツの長さ：0

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

経由SIP / 2.0 200 OK <allOneLine>：SIP / 2.0 / TLS b2bua.example.com;ブランチ= z9hG4bKnashdxyは、受信= 192.0。 2.2 </ allOneLine>から：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5に：アリス<SIP：Alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq： <一口：Alice@ua1.example.com>のContent-Length：154 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/8000

V = 0 0 =ユーザーA 2890844526 2890844526 IN IP4 ua1.example.com S =セッションのSDP C = IN IP4 ua1.example.com T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

ACK (8)

ACK（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

ACKのSIP：alice@ua1.example.com SIP / 2.0経由：SIP / 2.0 / TLS b2bua.example.com;ブランチ= z9hG4bKnashdxzから：キャロル<SIP：Carol@example.com>;タグ= 2ge46ab5へ：アリス<一口：Alice@example.com>;タグ= 13adc987のCall-ID：12345600@ua1.example.comのCSeq：3 ACKマックス・フォワード：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 0 =よびUserC 2890844546 2890844546 IN IP4 ua3.example.com S =セッションのSDP C = IN IP4 ua3.example.com T = 0、M =オーディオ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のセクション27.1のガイドライン[1]に従って、新しいSIPオプションタグを登録します。

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

この文書では、「から変更」SIPオプションタグを定義します。

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]いくつかの詳細にIdentityヘッダフィールドに関連するセキュリティ問題を論じています。半ば対話要求のFromヘッダーフィールドURIで接続されているIDを認証するためにIdentityヘッダーフィールドを使用している場合、同じ考慮事項が適用されます。

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.

有効なIdentityヘッダーフィールド（または認証の他の手段）は、この要求にまたはこのダイアログの以前の要求のいずれかで受信されなかったため、ダイアログ中のリクエストのヘッダフィールドURIから受信した非常に閉じた環境以外で（信頼することはできません）と有効なIdentityヘッダフィールドによってバックアップされていないダイアログ開始要求にFromヘッダーフィールドと同様に扱われることを期待されています。しかし、（これはコールの継続的な操作を妨げるため）Identityヘッダーフィールドが欠落していることを理由に、ダイアログ中のリクエストを拒否しないことをお勧めします。有効なIdentityヘッダフィールドが存在しない場合は、ユーザに与えられた情報に影響を与えることができます。ポリシーまたはユーザの好みが決まりあれば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.

（有効なIdentityヘッダフィールドを伴うヘッダからフィールドにおけるURI）中間ダイアログ要求に署名された接続識別は、ダイアログ内のピアUAに関する情報を提供します。ダイアログ形成要求にUASあった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.

署名した接続IDがダイアログ中のアイデンティティの変化を示しているとき同様に、そのようなアイデンティティの変更やその正当性の理由についての情報を伝達しません。

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に記載の方法で中間対話要求のFromヘッダフィールドにURIを移入することが期待される[3]。

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.

フランソワAudet、フランクDerks、ステファンのフライドポテト、ビジェイGurbani、カレン・ジェニングス、ポールKyzivat、ハンスPerssonの、ジョン・ピーターソン、エリックレスコラ、ジョナサン・ローゼンバーグ、志田シューベルト、雅 - チンタン、およびダンウィングのおかげで貴重なコメントを提供するため。

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]ローゼンバーグ、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] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.

[3]ピーターソン、J.とC.ジェニングスを、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。

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

[4]ローゼンバーグ、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]、RFC 3262、2002年6月ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。

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]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベストプラクティスの現在"、2002年6月。

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

[8]バーンズ、M.、 "リクエスト履歴情報のためのセッション開始プロトコル（SIP）への拡張"、RFC 4244、2005年11月。

Author's Address

著者のアドレス

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

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

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

電話：+44 115 943 4989 Eメール：john.elwell@siemens.com

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

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機能のための基金は現在、インターネット協会によって提供されます。