RFC4916 日本語訳
4916 Connected Identity in the Session Initiation Protocol (SIP). J.Elwell. June 2007. (Format: TXT=42924 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Elwell Request for Comments: 4916 Siemens Enterprise Communications Limited Updates: 3261 June 2007 Category: Standards Track
コメントを求めるワーキンググループJ.エルウェルの要求をネットワークでつないでください: 4916ジーメンスエンタープライズコミュニケーション株式会社は以下をアップデートします。 3261 2007年6月のカテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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にアイデンティティを供給して、そのアイデンティティがAuthentication Serviceによってサインされるという対話を形成する要求を受け取るSession Initiationプロトコル(SIP)ユーザエージェント(UA)に手段を提供します。 対話を形成する要求(Request-URIの値を変える)を「再-狙」うので、それ(UserエージェントServer、UAS)を受けるUAはToヘッダーフィールドでそれからの異なったアイデンティティを持つことができます。 対話の間、アイデンティティの変化を示すのに同じメカニズムを使用できます、例えば、ゲートウェイの後ろのPublic Switched Telephone Network(PSTN)での何らかの動作のために。 このドキュメントは標準に、RFC3261(SIP)をアップデートします。
Elwell Standards Track [Page 1] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[1ページ]RFC4916一口
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 ソリューション. . . . . . . . . . . . . . . . . . . . . 4 4の概観。 ふるまい. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1。 Existing Dialog. . . . . . . . 6 4.2のUAそのIssues INVITE Request Outside Contextのふるまい。 UAのふるまい、そのReceives、Existing Dialog. . . . . . . . 6 4.3のContextの外のINVITE Request アイデンティティが確立した招待で開始している対話. . . . . . . . . . . 7 4.4の間に変化するUAのふるまい。 一般UAのふるまい. . . . . . . . . . . . . . . . . . . 7 4.4.1。 要求. . . . . . . . . . . . . 7 4.4.2を中間の対話に送ります。 中間の対話要求. . . . . . . . . . . . 8 4.5を受け取ります。 認証サービスのふるまい. . . . . . . . . . . . . 8 4.6。 検証のふるまい. . . . . . . . . . . . . . . . . . . . 9 4.7。 プロキシのふるまい. . . . . . . . . . . . . . . . . . . . . 9 5。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1。 呼び出し. . . . 10 5.2に答えた後に、発信はアイデンティティを接続しました。 発信は呼び出し. . . . . 16 6の間、関連アイデンティティを改訂しました。 IANA問題. . . . . . . . . . . . . . . . . . . . . 21 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 21 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 22 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 23
Elwell Standards Track [Page 2] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[2ページ]RFC4916一口
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.
Session Initiationプロトコル、(SIP) (RFC3261[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:
このドキュメントは、一般的に「関連アイデンティティ」情報と呼ばれるもの(接続ユーザのアイデンティティ)を既存の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.
o 呼び出し転送などの呼び出し配列換えに続いて、訪問者か訪問される人を取り替えるユーザのアイデンティティは、第三者呼び出し制御方法を使用することでPSTN、または、背中合わせのユーザエージェント(B2BUA)の中の外まで運ばれました。
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を認証することにおける苦労がアイデンティティが応答でどうにか運ばれることであるなら、あることに注意してください。 別々の要求にアイデンティティを提供するのは、正常な認証のテクニックが使用されるのを許容します。
Elwell Standards Track [Page 3] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[3ページ]RFC4916一口
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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.
訪問者のアイデンティティ: 訪問者のアイデンティティ(Recordのアドレス)。
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.
訪問される人のアイデンティティ: 訪問される人のアイデンティティ(Recordのアドレス)。
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.
潜在的訪問される人: どんなUAのユーザも、早めの対話の構成をもたらしながらINVITE要求がどれであるかに狙いましたが、必ず電話口に出るユーザではなく、要求の平行であるか連続の分岐のために狙いました。
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.
関連アイデンティティ: 接続ユーザのアイデンティティ(Recordのアドレス)。
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.
中間の対話要求は、関連アイデンティティを提供するのに使用されます。 それのためのClient(UAC)が要求するUserエージェントは要求のFromヘッダーフィールドにアイデンティティを挿入します。 認証を提供してください、Identityヘッダーフィールド。(RFC4474[3])は中間の対話要求の経路の適当なAuthentication Serviceによって挿入されます。 UACで提供されない場合、Authentication Serviceは記録が発送するプロキシにあると予想されて、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が答えの前に要求するように同じ指示での要求は訪問者の変化を示すことができます。 答えた後のどちらかの指示での要求は接続ユーザの変化を示すことができます。 すべての場合では、そのような要求を送ることができる前に対話(早いか確認された)を確立しなければなりません。
Elwell Standards Track [Page 4] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[4ページ]RFC4916一口
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方法を使用します。(要求のためのRFC3311[4])、またはいくつかの事情の再INVITE方法。 訪問される人のアイデンティティを送るために、2xx応答をINVITE要求に送った後とACK要求を受け取った後に、INVITE要求のためのUASはUPDATE要求を送ります。 潜在的訪問される人のアイデンティティを送るために、RFC3262[5]が支持されると予想されます。 この場合、INVITE要求のためのUASはPRACK要求(信頼できる1xx応答をINVITE要求に送った後に、起こる)に受信して、応じた後に、UPDATE要求を送ります。 他の目的にも多分UPDATE要求を使用できました、例えば、(SDP)が早めのメディアのために提供するSession記述プロトコルと同時に潜在的訪問される人のアイデンティティを送るのに早めの対話の間、それを使用できました。 確立した呼び出しの間、接続アイデンティティ変化を示すために、UPDATE方法か再INVITE方法のどちらかを使用できます。 再INVITE方法は必要なら他の目的に使用されるでしょう(例えば、B2BUAはいつUAからSDP申し出に請求するというSDP申し出なしでそれが再INVITE要求を出さなければならないThirdパーティCall Control(3PCC)のテクニックを使用することで転送を実行しますか)。
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(タグでない)を変えることを中間の対話要求のToとFromヘッダーフィールドと彼らの応答に伴います、対話における要求と応答を形成する換算値と比べて。 ToとFromヘッダーフィールドURIを変えて、熟考されたコネセクション12.2.1は.1RFC3261[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を使用したRFC2543[6]との遅れている互換性のためにToからのURIとその後の要求の中のオリジナルの要求におけるFrom分野の用法をします。」 この仕様では、タグだけが対話識別に使用されます。 「中間の対話要求における、オリジナルのToとFrom 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.
したがって、このドキュメントは中間の対話要求と彼らの応答における、オリジナルのToとFrom URIの義務的な反映を非難します。(それは、RFC3261[1]への変化を構成します)。 このドキュメントはURIの変化を許容できないプロキシに備えないで、以来URIを変えるのはかなり長い間予想されました。 URIの変化、新しいオプションタグを許容できないどんなUAsも満たすために、Supportedヘッダーフィールドにおける、サポートの積極的なしるしを供給するために「変化」を導入します。 変えられたFromヘッダーフィールド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
また、FromヘッダーフィールドURIが関連アイデンティティを反映するために対話の間、変化するのを許容することに加えて、このドキュメントはFromのURIにおける関連アイデンティティを受けたUAを必要とします。
Elwell Standards Track [Page 5] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[5ページ]RFC4916一口
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.
そのUAによって送られたどんなその後の中間の対話要求のToヘッダーフィールドにもそのURIを使用するという中間の対話要求のヘッダーフィールド。
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
中間の対話要求の経路の適当なAuthentication Serviceが不在のとき、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. Existing DialogのUAそのIssues INVITE Request Outside Contextのふるまい
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はSupportedヘッダーフィールドに「変化」からのオプションタグを含まなければなりません。
Note that sending the "from-change" option tag does not guarantee
that connected identity will be received in subsequent requests.
「変化」からのオプションタグを送るのが、関連アイデンティティがその後の要求に受け取られるのを保証しないことに注意してください。
4.2. Behaviour of a UA that Receives an INVITE Request outside the
Context of an Existing Dialog
4.2. UAのふるまい、そのReceives、Existing DialogのContextの外のINVITE Request
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).
Supportedヘッダーフィールドで「変化」からのオプションタグを受け取ったなら早めの対話を形成した後にUA MAYはUPDATE要求を出します。(INVITEへの信頼できる暫定的な応答を送ったことを条件とした同じ対話のRFC3311[4])はPRACK要求に要求して、受けて、応じます。 Supportedヘッダーフィールドで「変化」からのオプションタグを受け取って、早めの対話で既にUPDATE要求を送らないなら完全な対話を形成した(2xxの最終的な応答をINVITE要求に送った後に)後に、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
URIがINVITE要求のToヘッダーフィールドURIにおいてそれと異ならないでも、新しい要求を送るのがAuthentication Serviceがこのアイデンティティの認証について断言するのを許容して、同輩UAにそれを確認することに注意してください、関連アイデンティティ
Elwell Standards Track [Page 6] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[6ページ]RFC4916一口
is the same as that in the To header field URI of the INVITE
request.
INVITE要求のToヘッダーフィールド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.
INVITEによって開始された対話の間、Supportedヘッダーフィールドで「変化」からのオプションタグを受け取っていて、UA変化(例えば、転送による)に関連しているアイデンティティがそのUAによって送られた要求のFromヘッダーフィールドで示された最後のアイデンティティと比較されたなら、FromヘッダーフィールドのURIにおける新しいアイデンティティを含んでいて、Uaは同じ対話で要求を出さなければなりません(匿名のアイデンティティが匿名であるなら必要です)。 再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.
中間の対話要求を送るとき、FromヘッダーフィールドURIに居住するとき、UaはRFC4474[3]の要件を観測しなければなりません、匿名を達成するための条項を含んでいて。
This will allow an Authentication Service on the path of the mid-
dialog request to insert an Identity header field.
これはIdentityヘッダーフィールドを挿入するという中間の対話要求の経路のAuthentication Serviceを許容するでしょう。
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の規則に従ってRFC3261[1]によると、対話の始めに修理されているよりこの.2通のドキュメントをむしろアップデートするためにこれが受けることがあるその対話のためのリモートURIの現行価値でToヘッダーフィールドURIに居住しなければなりません。
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.
改訂されたFromヘッダーフィールドURI(すなわち、要求を全く送らないならこの対話に関する前の要求のFromヘッダーフィールドで送られたURIかINVITEが要求する容認された対話形成のToヘッダーフィールドで比べて、復習する)との要求を送った後に、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-
UASが関連アイデンティティを受け入れないなら、RFC4474[3]によると、中間の対話要求を拒絶できます。 UACが428を受け取るなら、436、437、または中間の対話への438応答がそれを要求する、SHOULDは、対話が対話の場合で終えられるとみなします。
Elwell Standards Track [Page 7] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[7ページ]RFC4916一口
terminating request and SHOULD take no action in the case of any other request.
要求を終えて、SHOULDはいかなる他の要求の場合でも行動を全く取りません。
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がAuthentication Serviceの機能を管理しないので。
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 MAYはサインされて無記名のアイデンティティを区別します。 サインされたアイデンティティの場合では、要求の経路のVerifierの存在を当てにすることができないなら、UA SHOULDは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がFromヘッダーフィールドURIがオリジナルのINVITE要求のToヘッダーフィールドを送ったその対話に関する前の要求に受け取られたそれと異なっている同輩UAから中間の対話要求を受け取って、UAが2xx応答を送るなら、Uaはこの対話のためにリモートURIをアップデートしなければなりません、RFC3261[1]で定義されるように。 これで、UAが発信するというその後の要求のToヘッダーフィールドに新しい値を使用するでしょう、セクション4.4.1の規則に従って。 他の最終的な応答を送るなら、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.
[3] 中間の対話要求に対処するとき、RFC4474によると、Authentication Serviceは振る舞わなければなりません。
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.
FromヘッダーフィールドにおけるアイデンティティがUACが断言できるものでないならRFC4474がどう振る舞うかに関して静かであることに注意してください。そうすれば、したがって、Identityヘッダーフィールドなしで要求を拒絶するか、またはそれを進めるかが、ローカルの方針のための問題です。 中間の対話要求において、方針は他の要求と比べて異なっている場合があります。
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がこの仕様にAuthentication Serviceを一致させるとき、Fromヘッダーフィールドで特定された実体であるとして要求の送付者を認証できるべきである(認証のための正常な規則にかけます)、したがってできる注意はこのアイデンティティのための署名を提供します。 これは「再-狙」いと中間の対話アイデンティティ変化がFromヘッダーフィールドを要求の送付者を特定する手段として不正確にすることができるこの仕様を支持しないUAsと対照的になっています。
Elwell Standards Track [Page 8] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[8ページ]RFC4916一口
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.
中間の対話要求に対処するとき、以下で述べられるとしてアップデートされたRFC4474[3]によると、Authentication Serviceは振る舞わなければなりません。
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.
要求にIdentityヘッダーフィールドが全くなければ、RFC4474[3]は、428(Identity Headerを使用する)応答で要求を拒絶するかどうかが、方針の問題であると述べます。 UA MAYは他の要求と比べて中間の対話要求のための異なった方針を採ります。
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、そして/または、Fromヘッダーフィールド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.
中間の対話要求にAuthentication Serviceを提供できるプロキシはSupportedであるならルートを記録しなければなりません: 変化から、プロキシによって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ヘッダーフィールドにおける署名を発生させるのにAuthentication Serviceによって使用されます。
Elwell Standards Track [Page 9] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[9ページ]RFC4916一口
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
-----END RSA PRIVATE KEY-----
-----RSA秘密鍵を始めてください。----- MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30; tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk-----終わりのRSA秘密鍵-----
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要求(ボブ)のToヘッダーフィールドにおいてそれと等しくはありません。 キャロルのUAはUPDATE要求のFromヘッダーフィールドにおけるキャロルのアイデンティティを伝えます。 プロキシは、また、Authentication Serviceを提供して、したがって、IdentityとIdentity-インフォメーションヘッダーフィールドをUPDATE要求に追加します。
Alice's UA PROXY + Carol's UA
Authentication
Service
アリスのUaのプロキシ+キャロルのUA認証サービス
INVITE(1) INVITE(2)
----------------> ---------------->
(1) 招待(2)を招待してください。---------------->。---------------->。
200(4) 200(3)
<---------------- <----------------
200(4) 200(3)<。---------------- <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--
ACK(5) ACK(6)
----------------> ---------------->
ACK(5) ACK(6)---------------->。---------------->。
UPDATE(8) UPDATE(7)
<---------------- <----------------
アップデート(8)アップデート(7)<。---------------- <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--
200(9) 200(10)
----------------> ---------------->
200(9) 200(10) ---------------->。---------------->。
Elwell Standards Track [Page 10] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[10ページ]RFC4916一口
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
INVITE一口: Bob@example.com SIP/2.0Via: 一口/2.0/TLS ua1.example.com; ブランチ=z9hG4bKnashds8To: ボブ<一口: bob@example.com 、gt;、From: アリス<一口: alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 前方へマックスを招待してください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒は以下を許容します。 招待、ACK、キャンセル、オプション、さようならアップデートが支持した: 変化からのContact: <一口: alice@ua1.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 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
0 0IN v=0 o=UserA2890844526 2890844526IN IP4 ua1.example.com s=セッションSDP c=IP4 ua1.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
Elwell Standards Track [Page 11] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[11ページ]RFC4916一口
INVITE (2):
(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
INVITE一口: Carol@ua2.example.com SIP/2.0Via: 一口/2.0/TLS proxy.example.com; ブランチは以下を通ってz9hG4bK776asdhds<allOneLine>と等しいです。 一口/2.0/TLS ua1.example.com; ブランチはz9hG4bKnashds8と等しいです; 容認された=192.0.2。 1 </allOneLine>To: ボブ<一口: bob@example.com 、gt;、From: アリス<一口: alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 前方へマックスを招待してください: 69 日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒は以下を許容します。 招待、ACK、キャンセル、オプション、さようならアップデートが支持した: 変化からのContact: <一口: alice@ua1.example.com 、gt;、記録的なルート: <一口: proxy.example.com; lr><allOneLine>のアイデンティティ: 「xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1 3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc=」allOneLine>アイデンティティ</インフォメーション: <https://example.com/example.cer>; alg=rsa-sha1コンテントタイプ: sdp Contentアプリケーション/長さ: 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
0 0IN v=0 o=UserA2890844526 2890844526IN IP4 ua1.example.com s=セッションSDP c=IP4 ua1.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
Elwell Standards Track [Page 12] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[12ページ]RFC4916一口
200 (3):
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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS proxy.example.com; ブランチはz9hG4bK776asdhdsと等しいです; 容認された=192。 0.2.2 以下を通って</allOneLine><allOneLine>。 一口/2.0/TLS ua1.example.com; ブランチはz9hG4bKnashds8と等しいです; 容認された=192.0.2。 1 <allOneLine>To: ボブ<一口: bob@example.com 、gt;、;=2ge46ab5From:にタグ付けをしてください アリス<一口: alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 招待は以下を許容します。 招待、ACK、キャンセル、オプション、さようならアップデートが支持した: 変化からのContact: <一口: carol@ua2.example.com 、gt;、記録的なルート: <一口: proxy.example.com; lr>コンテントタイプ: sdp Contentアプリケーション/長さ: 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
0 0IN v=0 o=UserB2890844536 2890844536IN IP4 ua2.example.com s=セッションSDP c=IP4 ua2.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS ua1.example.com; ブランチはz9hG4bKnashds8と等しいです; 容認された=192.0.2。 1 </allOneLine>To: ボブ<一口: bob@example.com 、gt;、;=2ge46ab5From:にタグ付けをしてください アリス<一口: alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 招待は以下を許容します。 招待、ACK、キャンセル、オプション、さようならアップデートが支持した: 変化からのContact: <一口: carol@ua2.example.com 、gt;、記録的なルート: <一口: proxy.example.com; lr>コンテントタイプ: sdp Contentアプリケーション/長さ: 154
Elwell Standards Track [Page 13] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[13ページ]RFC4916一口
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
0 0IN v=0 o=UserB2890844536 2890844536IN IP4 ua2.example.com s=セッションSDP c=IP4 ua2.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/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一口: carol@ua2.example.com SIP/2.0Via: 一口/2.0/TLS ua1.example.com; ブランチ=z9hG4bKnashds9From: アリス<一口: Alice@example.com 、gt;、;=13adc987To:にタグ付けをしてください ボブ<一口: Bob@example.com 、gt;、; =2ge46ab5呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 前方へACKマックス: 70ルート: <一口: proxy.example.com; lr>コンテンツの長さ: 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一口: carol@ua2.example.com SIP/2.0Via: 一口/2.0/TLS proxy.example.com; ブランチは以下を通ってz9hG4bK776asdhdt<allOneLine>と等しいです。 一口/2.0/TLS ua1.example.com; ブランチはz9hG4bKnashds9と等しいです; 容認された=192.0.2。 1 </allOneLine>From: アリス<一口: Alice@example.com 、gt;、;=13adc987To:にタグ付けをしてください ボブ<一口: Bob@example.com 、gt;、; =2ge46ab5呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 前方へACKマックス: 69 コンテンツの長さ: 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
UPDATE一口: Alice@ua1.example.com SIP/2.0Via: 一口/2.0/TLS ua2.example.com; ブランチ=z9hG4bKnashdt1From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 2 前方へマックスをアップデートしてください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時2分15秒のルート: <一口: proxy.example.com; lr>接触: <一口: Carol@ua2.example.com 、gt;、コンテンツの長さ: 0
Elwell Standards Track [Page 14] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[14ページ]RFC4916一口
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ヘッダーフィールドにおけるURIがINVITE要求/応答におけるToヘッダーフィールドにおいてそれと異なっていることに注意してください。 しかしながら、タグはINVITE応答におけるそれと同じです。
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
UPDATE一口: Alice@ua1.example.com SIP/2.0Via: 一口/2.0/TLS proxy.example.com; ブランチは以下を通ってz9hG4bK776asdhdu<allOneLine>と等しいです。 一口/2.0/TLS ua2.example.com; ブランチはz9hG4bKnashdt1と等しいです; 容認された=192.0.2。 3 </allOneLine>From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 2 前方へマックスをアップデートしてください: 69 日付: グリニッジ標準時2002年2月21日木曜日13時2分15秒の接触: <一口: Carol@ua2.example.com 、gt;、<allOneLine>のアイデンティティ: 「g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9 KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko=」allOneLine>アイデンティティ</インフォメーション: <https://example.com/本命>; alg=rsa-sha1コンテンツの長さ: 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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS proxy.example.com; ブランチはz9hG4bK776asdhduと等しいです; 容認された=192。 0.2.2 以下を通って</allOneLine><allOneLine>。 一口/2.0/TLS ua2.example.com; ブランチはz9hG4bKnashdt1と等しいです; 容認された=192.0.2。 3 </allOneLine>From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 2 接触をアップデートしてください: <一口: Alice@ua1.example.com 、gt;、コンテンツの長さ: 0
Elwell Standards Track [Page 15] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[15ページ]RFC4916一口
200 (10):
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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS ua2.example.com; ブランチはz9hG4bKnashdt1と等しいです; 容認された=192.0.2。 3 </allOneLine>From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 2 接触をアップデートしてください: <一口: Alice@ua1.example.com 、gt;、コンテンツの長さ: 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要求で伝えられます。 そして、B2BUAは、RFC3725[7](例えば、クリックからダイヤルへのアプリケーションのコントロールの下における)で説明されるように第三者呼び出し規制(3PCC)のテクニックを使用することで呼び出し転送を実行します。 その結果、アリスはキャロルに接続されるように(また、示されなかった)なります、そして、セッションが再交渉されるのを許容しながら、再INVITE要求は出されます。 B2BUAはAuthentication Serviceを提供して、その結果、キャロルのアイデンティティの認証を提供するという再INVITE要求におけるIdentityヘッダーフィールドを発生させます。
Elwell Standards Track [Page 16] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[16ページ]RFC4916一口
Alice's UA B2BUA
アリスのUA B2BUA
INVITE(1)
---------------->
(1)を招待してください。---------------->。
200(2)
<----------------
200(2)<。----------------
ACK(3)
---------------->
ACK(3)---------------->。
UPDATE(4)
<----------------
アップデート(4)<。----------------
200(5)
---------------->
200(5) ---------------->。
re-INVITE(6)
<----------------
(6) <を再招待してください。----------------
200(7)
---------------->
200(7) ---------------->。
ACK(8)
<---------------
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
INVITE一口: Bob@example.com SIP/2.0Via: 一口/2.0/TLS ua1.example.com; ブランチ=z9hG4bKnashds8To: ボブ<一口: bob@example.com 、gt;、From: アリス<一口: alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 前方へマックスを招待してください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒は以下を許容します。 招待、ACK、キャンセル、オプション、さようならアップデートが支持した: 変化からのContact: <一口: alice@ua1.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 154
Elwell Standards Track [Page 17] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[17ページ]RFC4916一口
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
0 0IN v=0 o=UserA2890844526 2890844526IN IP4 ua1.example.com s=セッションSDP c=IP4 ua1.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS ua1.example.com; ブランチはz9hG4bKnashds8と等しいです; 容認された=192.0.2。 1 </allOneLine>To: ボブ<一口: bob@example.com 、gt;、;=2ge46ab5From:にタグ付けをしてください アリス<一口: alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 招待は以下を許容します。 招待、ACK、キャンセル、オプション、さようならアップデートが支持した: 変化からのContact: <一口: xyz@b2bua.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 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
0 0IN v=0 o=UserB2890844536 2890844536IN IP4 ua2.example.com s=セッションSDP c=IP4 ua2.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/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一口: xyz@b2bua.example.com SIP/2.0Via: 一口/2.0/TLS ua1.example.com; ブランチ=z9hG4bKnashds9From: アリス<一口: Alice@example.com 、gt;、;=13adc987To:にタグ付けをしてください ボブ<一口: Bob@example.com 、gt;、; =2ge46ab5呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 1 前方へACKマックス: 70 コンテンツの長さ: 0
Elwell Standards Track [Page 18] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[18ページ]RFC4916一口
UPDATE (4)
アップデート(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一口: alice@ua1.example.com SIP/2.0Via: 一口/2.0/TLS b2bua.example.com; ブランチ=z9hG4bKnashdt1From: ボブ<一口: Bob@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 2 前方へマックスをアップデートしてください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時2分12秒の接触: <一口: xyz@b2bua.example.com 、gt;、<allOneLine>のアイデンティティ: 「AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E=」allOneLine>アイデンティティ</インフォメーション: <https://example.com/本命>; alg=rsa-sha1コンテンツの長さ: 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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS b2bua.example.com; ブランチはz9hG4bKnashdt1と等しいです; 容認された=192.0。 2.2 </allOneLine>From: ボブ<一口: Bob@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 2 接触をアップデートしてください: <一口: Alice@ua1.example.com 、gt;、コンテンツの長さ: 0
Elwell Standards Track [Page 19] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[19ページ]RFC4916一口
re-INVITE (6)
再招待(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
INVITE一口: alice@ua1.example.com SIP/2.0Via: 一口/2.0/TLS b2bua.example.com; ブランチ=z9hG4bKnashdxy From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 3 前方へマックスを招待してください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時3分20秒の接触: <一口: xyz@b2bua.example.com 、gt;、<allOneLine>のアイデンティティ: 「KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U 3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo=」allOneLine>アイデンティティ</インフォメーション: <https://example.com/本命>; alg=rsa-sha1コンテンツの長さ: 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
一口/2.0 200は以下を通って<allOneLine>を承認します。 一口/2.0/TLS b2bua.example.com; ブランチはz9hG4bKnashdxyと等しいです; 容認された=192.0。 2.2 </allOneLine>From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 3 接触を招いてください: <一口: Alice@ua1.example.com 、gt;、コンテンツの長さ: 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
0 0IN v=0 o=UserA2890844526 2890844526IN IP4 ua1.example.com s=セッションSDP c=IP4 ua1.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
Elwell Standards Track [Page 20] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[20ページ]RFC4916一口
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一口: alice@ua1.example.com SIP/2.0Via: 一口/2.0/TLS b2bua.example.com; ブランチ=z9hG4bKnashdxz From: キャロル<一口: Carol@example.com 、gt;、;=2ge46ab5To:にタグ付けをしてください アリス<一口: Alice@example.com 、gt;、; =13adc987呼び出しIDにタグ付けをしてください: 12345600@ua1.example.com CSeq: 3 前方へACKマックス: 70 コンテンツの長さ: 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
0 0IN v=0 o=UserC2890844546 2890844546IN IP4 ua3.example.com s=セッションSDP c=IP4 ua3.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/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].
この仕様はRFC3261[1]のセクション27.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 Parameter Registryの「オプションタグ」セクションに以下の列を追加してあります:
+------------+------------------------------------------+-----------+ | 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. | | +------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+ | 名前| 記述| 参照| +------------+------------------------------------------+-----------+ | 変化| このオプションタグは、それを示すのに使用されます。| [RFC4916]| | | UAはFromでURIへの変化を支持します。| | | | そして、対話の間のToヘッダーフィールド。 | | +------------+------------------------------------------+-----------+
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.
RFC4474[3]は何らかの詳細にIdentityヘッダーフィールドに関連するセキュリティ問題について議論します。 中間の対話要求のFromヘッダーフィールドURIにおける関連アイデンティティを認証するのに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
どんな有効なIdentityヘッダーフィールド(または、認証の他の手段)もこの要求かこれに関する以前の要求に受け取られていない中間の対話要求における容認されたFromヘッダーフィールドURI
Elwell Standards Track [Page 21] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[21ページ]RFC4916一口
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ヘッダーフィールドによって支援されない対話を開始する要求における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ヘッダーフィールドによって伴われたFromヘッダーフィールドにおけるURI)におけるサインされた関連アイデンティティは同輩UAの情報を対話に提供します。 対話を形成する要求でUASであったUAの場合では、このアイデンティティは必ず要求を形成するのにおいて対話のToヘッダーフィールドにおけるそれと同じであるというわけではありません。 対話を形成する要求のルーティングの間、「再-狙」うので、これはそうです。 サインされた関連アイデンティティは、そのような「再-狙」いの合法性に関して沈黙しますが、単に、それが「再-狙」うという結果を反映します。 履歴情報、(接続ユーザがどう連絡されたかに関してRFC4244[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.
URI計画が機会を最小にすることができる一口の使用は呼び出し設立時間か呼び出しの間、どの不適当な接続アイデンティティ情報を送るかで攻撃されます。
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が方法で中間の対話要求のヘッダーフィールドがRFC4474[3]で説明したFromで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.
フランソアAudet、フランクDerks、ステファン・フリーズ、ビジェイGurbani、Cullenジョニングス、ポールKyzivat、ハンス・ペルソン、ジョン・ピーターソン、エリック・レスコラ、ジョナサン・ローゼンバーグ、志太シューベルト、Ya-チンTan、およびダンWingに貴重なコメントを提供してくださってありがとうございます。
Elwell Standards Track [Page 22] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[22ページ]RFC4916一口
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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[3] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
[4] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年9月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[5] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、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] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、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.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、RFC3725、2002年6月。
[8] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244, November 2005.
[8] バーンズ、M.、「要求履歴情報のためのセッション開始プロトコル(一口)への拡大」、RFC4244、2005年11月。
Author's Address
作者のアドレス
John Elwell Siemens Enterprise Communications Limited Technology Drive Beeston, Nottingham NG9 1LA UK
ジョン・エルウェル・ジーメンスエンタープライズコミュニケーション株式会社技術Driveビーストン、ノッティンガムNG9 1LAイギリス
Phone: +44 115 943 4989 EMail: john.elwell@siemens.com
以下に電話をしてください。 +44 4989年の115 943メール: john.elwell@siemens.com
Elwell Standards Track [Page 23] RFC 4916 SIP Connected ID June 2007
ID2007年6月に接続されたエルウェル標準化過程[23ページ]RFC4916一口
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Elwell Standards Track [Page 24]
エルウェル標準化過程[24ページ]
一覧
スポンサーリンク
