RFC3892 日本語訳

3892 The Session Initiation Protocol (SIP) Referred-By Mechanism. R.Sparks. September 2004. (Format: TXT=52441 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          R. Sparks
Request for Comments: 3892                                          Xten
Category: Standards Track                                 September 2004

スパークがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3892年のXtenカテゴリ: 標準化過程2004年9月

      The Session Initiation Protocol (SIP) Referred-By Mechanism

参照されたセッション開始プロトコル(一口)メカニズム

Status of this Memo

この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 Internet Society (2004).

Abstract

要約

   The Session Initiation Protocol (SIP) REFER method provides a
   mechanism where one party (the referrer) gives a second party (the
   referee) an arbitrary URI to reference.  If that URI is a SIP URI,
   the referee will send a SIP request, often an INVITE, to that URI
   (the refer target).  This document extends the REFER method, allowing
   the referrer to provide information about the REFER request to the
   refer target using the referee as an intermediary.  This information
   includes the identity of the referrer and the URI to which the
   referrer referred.  The mechanism utilizes S/MIME to help protect
   this information from a malicious intermediary.  This protection is
   optional, but a recipient may refuse to accept a request unless it is
   present.

Session Initiationプロトコル(SIP)REFER方法は1回のパーティー(リファラー)が2番目のパーティー(レフリー)に任意のURIを与えるメカニズムを参照に提供します。そのURIがSIP URIであるなら、レフリーはSIP要求、しばしばINVITEを送るでしょう、そのURIに(参照、目標) このドキュメントがREFER要求の情報を提供するためにリファラーを許容するREFER方法を広げている、仲介者としてレフリーを使用することで目標を示してください。この情報はリファラーが参照されたリファラーとURIのアイデンティティを含んでいます。メカニズムは、悪意がある仲介者からこの情報を保護するのを助けるのにS/MIMEを利用します。この保護は任意ですが、それが存在していない場合、受取人は、申し込みに応じるのを拒否するかもしれません。

Sparks                      Standards Track                     [Page 1]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[1ページ]RFC3892をかきたてます。

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Requirements Notation  . . . . . . . . . . . . . . . . .  3
   2.  The Referred-By Mechanism  . . . . . . . . . . . . . . . . . .  3
       2.1.  Referrer Behavior  . . . . . . . . . . . . . . . . . . .  4
       2.2.  Referee Behavior . . . . . . . . . . . . . . . . . . . .  4
       2.3.  Refer Target Behavior  . . . . . . . . . . . . . . . . .  5
   3.  The Referred-By Header Field . . . . . . . . . . . . . . . . .  6
   4.  The Referred-By Token  . . . . . . . . . . . . . . . . . . . .  7
       4.1.  Refer Target Inspection of a Referred-By Token . . . . .  8
   5.  The 429 Provide Referrer Identity Error Response . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
       6.1.  Identifying the Referee in the Referred-by Token . . . . 10
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       7.1.  Basic REFER  . . . . . . . . . . . . . . . . . . . . . . 11
       7.2.  Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
       7.3.  Requiring Referrer Identity  . . . . . . . . . . . . . . 14
       7.4.  Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       10.1. Normative References . . . . . . . . . . . . . . . . . . 23
       10.2. Informative References . . . . . . . . . . . . . . . . . 24
   11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25

1. 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。要件記法. . . . . . . . . . . . . . . . . 3 2 参照されたメカニズム. . . . . . . . . . . . . . . . . . 3 2.1。リファラーの振舞い. . . . . . . . . . . . . . . . . . . 4 2.2。振舞い. . . . . . . . . . . . . . . . . . . . 4 2.3を仲裁してください。標的行動. . . . . . . . . . . . . . . . . 5 3を参照してください。参照されたヘッダーフィールド. . . . . . . . . . . . . . . . . 6 4。参照された象徴. . . . . . . . . . . . . . . . . . . . 7 4.1。参照された象徴. . . . . 8 5の目標点検を参照してください。 429はリファラーアイデンティティ誤り応答. . . . . . . 8 6を提供します。セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 6.1。参照された象徴. . . . 10 7でレフリーを特定します。例. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1。基礎は.117.2を参照します。不安定である、.147.3に参照してください。リファラーのアイデンティティ. . . . . . . . . . . . . . 14 7.4を必要とします。入れ子にされて、.188を参照してください。 IANA問題. . . . . . . . . . . . . . . . . . . . . 23 9。貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 23 10。参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1。引用規格. . . . . . . . . . . . . . . . . . 23 10.2。有益な参照. . . . . . . . . . . . . . . . . 24 11。作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 24 12。完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 25

1.  Overview

1. 概観

   The SIP REFER method [2] provides a mechanism where one party (the
   referrer) provides a second party (the referee) with an arbitrary URI
   to reference.  If that URI is a SIP URI, the referee will send a SIP
   request, often an INVITE, to that URI (the refer target).  Nothing
   provided in [2] distinguishes this referenced request from any other
   request the referee might have sent to the refer target.

SIP REFER方法[2]は1回のパーティー(リファラー)が2番目のパーティー(レフリー)を任意のURIに供給するメカニズムを参照に提供します。そのURIがSIP URIであるなら、レフリーはSIP要求、しばしばINVITEを送るでしょう、そのURIに(参照、目標) [2]に提供されたものは何もレフリーが発信したかもしれないいかなる他の要求ともこの参照をつけられた要求を区別しない、目標を参照してください。

      Referrer           Referee            Refer Target
         |                  |                    |
         | REFER            |                    |
         | Refer-To: target |                    |
         |----------------->| INVITE target      |
         |                  |------------------->|

Sparks                      Standards Track                     [Page 2]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[2ページ]RFC3892をかきたてます。

   There are applications of REFER, such as call transfer [8], where it
   is desirable to provide the refer target with particular information
   about the referrer and the REFER request itself.  This information
   may include, but is not limited to, the referrer's identity, the
   referred to URI, and the time of the referral.  The refer target can
   use this information when deciding whether to admit the referenced
   request.  This document defines one set of mechanisms to provide that
   information.

REFERの利用があります、呼び出し転送[8]などのようにリファラーの特定の情報で目標を参照してください。そうすれば、REFERはそれ自体を要求します。(そこでは、提供するのが望ましいです)。この情報は、包含するかもしれませんが、有限でなくて、リファラーのアイデンティティと、URIの参照と、紹介の時間です。目標を参照してください。参照をつけられた要求を認めるかどうか決めるとき、この情報を使用できます。このドキュメントは、その情報を提供するために1セットのメカニズムを定義します。

   All of the mechanisms in this document involve placing information in
   the REFER request that the referee copies into the referenced
   request.  This necessarily establishes the referee as an eavesdropper
   and places the referee in a position to launch man-in-the-middle
   attacks on that information.

メカニズムのすべてが、レフリーが参照をつけられた要求にコピーするというREFER要求における情報を置くことを本書では伴います。これは、必ず立ち聞きする者とレフリーを書き立てて、その情報で介入者攻撃に着手する立場にレフリーを置きます。

   At the simplest level, this document defines a mechanism for carrying
   the referrer's identity, expressed as a SIP URI in a new header:
   Referred-By.  The refer target can use that information, even if it
   has not been protected from the referee, at the perils and with the
   limitations documented here.  The document proceeds to define an
   S/MIME based mechanism for expressing the identity of the referrer
   and capturing other information about the REFER request, allowing the
   refer target to detect tampering (and other undesirable behaviors) by
   the referee.

最も簡単なレベルでは、このドキュメントはSIP URIとして新しいヘッダーで言い表されたリファラーのアイデンティティを運ぶためにメカニズムを定義します: 参照にされる。その情報、それがレフリーから危険で保護されていないおよび制限がここに記録されている状態で、目標缶の使用を参照してください。ドキュメントはリファラーのアイデンティティを言い表して、REFER要求の他の情報を得るためにS/MIMEのベースのメカニズムを定義しかけます、許容している、レフリーによるいじること(そして、他の好ましくない行動)を検出するのに目標を参照してください。

1.1.  Requirements Notation

1.1. 要件記法

   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 BCP 14, RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。

2.  The Referred-By Mechanism

2. 参照されたメカニズム

   The following figure summarizes how Referred-By information is
   carried to the Refer Target.  The Referrer provides a Referred-By
   header with its SIP address-of-record, optionally associating an
   S/MIME protected token reflecting the identity of the referrer and
   the details of the REFER request.  The Referee copies this header and
   the token, if provided, into the triggered request (shown here as an
   INVITE).

以下の図は近くReferred情報がどうRefer Targetまで運ばれるかをまとめます。 Referrerは近くReferredヘッダーにSIP記録されている住所を提供します、任意にリファラーのアイデンティティとREFER要求の詳細を反映するS/MIMEの保護された象徴を関連づけて。引き起こされた要求(ここに、INVITEとして示す)に提供するなら、Refereeはこのヘッダーと象徴をコピーします。

Sparks                      Standards Track                     [Page 3]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[3ページ]RFC3892をかきたてます。

   Referrer                       Referee                   Refer Target
      |                              |                             |
      | REFER                        |                             |
      | Refer-To: target             |                             |
      | Referred-By: referrer;cid=X  |                             |
      |                              |                             |
      | (one of the body parts is)   |                             |
      | Content-ID: X                |                             |
      | <Referred-By Token>          |                             |
      |----------------------------->|                             |
      |                              | INVITE target               |
      |                              | Referred-By: referrer;cid=X |
      |                              |                             |
      |                              | (one of the body parts is)  |
      |                              | Content-ID: X               |
      |                              | <Referred-By token>         |
      |                              |---------------------------->|

2.1.  Referrer Behavior

2.1. リファラーの振舞い

   A UA sending a REFER request (a referrer) MAY provide a Referred-By
   header field value in the request.  A REFER request MUST NOT contain
   more than one Referred-By header field value.

REFER要求(リファラー)を送るUAは要求でヘッダーフィールド値を近くReferredに供給するかもしれません。 REFER要求は1つ以上の近くReferredヘッダーフィールド価値を含んではいけません。

   A referrer MAY include a Referred-By token in a REFER request.  A
   REFER request containing a Referred-By token MUST contain a
   Referred-By header field value with a cid parameter value equal to
   the Content-ID of the body part containing the token.

リファラーはREFER要求に近くReferred象徴を含むかもしれません。近くReferred象徴を含むREFER要求は象徴を含む身体の部分のコンテントIDと等しいCidパラメタ価値がある近くReferredヘッダーフィールド価値を含まなければなりません。

   The referrer will receive a NOTIFY with a message/sipfrag [4] body
   indicating a final response of 429 "Provide Referrer Identity" to the
   referenced request if the refer target requires a valid Referred-By
   token to accept the request.  This can occur when either no token is
   provided or a provided token is invalid.

目標を参照してください。メッセージ/sipfrag[4]ボディーが429の最終的な応答「リファラーのアイデンティティを提供してください」を示していてリファラーが参照をつけられた要求にNOTIFYを受ける、要請を受け入れるために有効な近くReferred象徴を必要とします。象徴を全く提供しないか、または提供された象徴が無効であるときに、これは起こることができます。

   The referrer will receive a 429 "Provide Referrer Identity" response
   to the REFER if the referee requires a Referred-By token to be
   present in order to accept the REFER.

レフリーが、REFERを受け入れるために近くReferred象徴が現在であるのを必要とすると、リファラーはREFERへの「リファラーのアイデンティティを提供してください」という429応答を受けるでしょう。

   If a referrer wishes to re-attempt to refer a referee after receiving
   a 429 response or a NOTIFY containing a 429, it MAY submit a new
   REFER request containing a Referred-By token.

リファラーであるなら、429応答かa429を含むNOTIFYを受けた後にaを参照するのを再試みるという願望は審判員を勤めて、それは近くReferred象徴を含む新しいREFER要求を提出するかもしれません。

2.2.  Referee Behavior

2.2. レフリーの振舞い

   A UA accepting a REFER request (a referee) to a SIP URI (using either
   the sip: or sips: scheme) MUST copy any Referred-By header field
   value and token into the referenced request without modification.

SIP URI(: 一口: 一口を使用して、計画する)にREFER要求(レフリー)を受け入れるUAは変更なしでどんな近くReferredヘッダーフィールド価値と象徴も参照をつけられた要求にコピーしなければなりません。

Sparks                      Standards Track                     [Page 4]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[4ページ]RFC3892をかきたてます。

   A referee MAY reject a REFER request that does not contain a
   Referred-By token with a 429 "Provide Referrer Identity" response.  A
   referee SHOULD NOT reject a request that contains a Referred-By token
   encrypted to a key it does not possess simply because it cannot
   decrypt the token.  (One scenario where such rejection would be
   appropriate is when the referee is attempting to remain anonymous
   (see Section 6.1).)  Note that per [3], the referee should still be
   able to verify the signature of such an encrypted token.

レフリーは「リファラーのアイデンティティを提供してください」という429応答で近くReferred象徴を含まないREFER要求を拒絶するかもしれません。 AレフリーSHOULD NOTは単に象徴を解読することができないのでそれが所有していないキーにコード化された近くReferred象徴を含む要求を拒絶します。 (そのような拒絶が適切である1つのシナリオがレフリーが匿名のままで残っているのを試みている(セクション6.1を見てください)時です。) レフリーが[3]単位でまだそのようなコード化された象徴の署名について確かめることができるべきであることに注意してください。

   A referee SHOULD present the same identity to the referrer and the
   refer target.

そして、審判員を勤める、SHOULDがリファラーへの同じアイデンティティを提示する目標を参照してください。

2.3.  Refer Target Behavior

2.3. 標的行動を参照してください。

   A UA receiving a non-REFER SIP request MAY inspect the request for a
   Referred-By header field and token.

非REFER SIP要求を受け取るUAは近くReferredヘッダーフィールドと象徴を求める要求を点検するかもしれません。

   If a Referred-By header field value is not present, this UA cannot
   distinguish this request from any other the UA acting as the referee
   might have sent.  Thus, the UA would apply exactly the admissions
   policies and processing described in [5] to the request.

近くReferredヘッダーフィールド価値が存在していないと、このUAはレフリーとしてのUA芝居が送ったかもしれないいかなる他のもこの要求を区別できません。したがって、UAはまさに[5]で要求に説明された入場方針と処理を適用するでしょう。

   If a Referred-By header field value is present, the receiving UA can
   consider itself a refer target and MAY apply additional admission
   policies based on the contents of the Referred-By header field and
   token.

近くReferredヘッダーフィールド価値が存在しているなら、受信UAはaが目標を参照するとそれ自体で考えることができて、近くReferredヘッダーフィールドと象徴のコンテンツに基づく追加入場方針を申し込むかもしれません。

   The referee is in a position to modify the contents of the Referred-
   By header field value, or falsely provide one even if no REFER
   actually exists.  If such behavior could affect admission policy
   (including influencing the agent's user by rendering misleading
   content), the refer target SHOULD require that a valid Referred-By
   token be present.

どんなREFERも実際に存在していなくても、レフリーはヘッダーフィールドによるReferred価値のコンテンツを変更するか、または間違って1つを提供する立場にいます。参照してください。そのような振舞いが入場方針(紛らわしい内容を表すことによってエージェントのユーザに影響を及ぼすのを含んでいる)に影響するかもしれないなら必要である、目標SHOULDは、有効な近くReferred象徴が存在しているのを必要とします。

   The refer target MAY reject a request if no Referred-By token is
   present or if the token is stale using the 429 "Provide Referrer
   Identity" error response defined in Section 5.  The 428 error
   response from [7] is not appropriate for this purpose - it is needed
   for the refer target to request an authentication token from the
   referee.

どんな近くReferred象徴も存在していないか、または象徴が429誤り応答がセクション5で定義した「リファラーのアイデンティティを提供してください」を使用することで聞き古したである、目標5月の廃棄物a要求を参照してください。 [7]からの428誤り応答はこのために適切ではありません--それが必要である、レフリーから認証象徴を要求するのに目標を参照してください。

   If no Referred-By token is present, the refer target MAY proceed with
   processing the request.  If the agent provides any information from
   the Referred-By header to its user as part of processing the request,
   it MUST notify the user that the information is suspect.

どんな近くReferred象徴も存在していないなら参照する、要求を処理する5月が続ける目標を参照してください。エージェントが処理の一部としてのどんな近くReferredヘッダーからユーザまでの情報にも要求を提供するなら、それは、情報が疑わしいようにユーザに通知しなければなりません。

   The refer target MUST reject an otherwise well-formed request with an
   invalid Referred-By token (see Section 4) with a 429 error response.

目標を参照してください。429誤り応答で無効の近くReferred象徴(セクション4を見る)によるそうでなければ、よく形成された要求を拒絶しなければなりません。

Sparks                      Standards Track                     [Page 5]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[5ページ]RFC3892をかきたてます。

3.  The Referred-By Header Field

3. 参照されたヘッダーフィールド

   Referred-By is a request header field as defined by [5].  It can
   appear in any request.  It carries a SIP URI representing the
   identity of the referrer and, optionally, the Content-ID of a body
   part (the Referred-By token) that provides a more secure statement of
   that identity.

参照されているのは、[5]によって定義される要求ヘッダーフィールドです。それはどんな要求にも現れることができます。それはそのアイデンティティの、より安全な声明を提供するリファラーのアイデンティティと任意に身体の部分のコンテントID(近くReferred象徴)を表すSIP URIを運びます。

      Referred-By  =  ("Referred-By" / "b") HCOLON referrer-uri
                     *( SEMI (referredby-id-param / generic-param) )

参照された=(/「b」を「参照する」)HCOLONリファラー-uri*(SEMI(一般的なreferredbyイドparam/param))

      referrer-uri = ( name-addr / addr-spec )

リファラー-uri=(名前addr / addr仕様)

      referredby-id-param = "cid" EQUAL sip-clean-msg-id

referredbyイドparamは「Cid」EQUALと清潔なmsgイドをちびちび飲んだ状態で等しいです。

      sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT

清潔なmsgイドをちびちび飲んでいる=LDQUOTドット原子"@"(ドット原子/ホスト)RDQUOT

      dot-atom = atom *( "." atom )

ドット原子=原子*(「. 」原子、)

      atom     = 1*( alphanum / "-" / "!" / "%" / "*" /
                          "_" / "+" / "'" / "`" / "~"   )

原子=1*(alphanum/「-」/“!"/「%」/「*」/"_"/「+」/、「'、「/、「'「/「~」)」'

   Since the Content-ID appears as a SIP header parameter value which
   must conform to the expansion of the gen-value defined in [5], this
   grammar produces values in the intersection of the expansions of
   gen-value and msg-id from [9].  The double-quotes surrounding the
   sip-clean-msg-id MUST be replaced with left and right angle brackets
   to derive the Content-ID used in the message's MIME body.  For
   example,

コンテントIDが値に情報を得ている定義されたコネ[5]の拡大に従わなければならないSIPヘッダーパラメタ価値として現れるので、この文法は[9]からの値に情報を得てmsgイドの拡大の交差点で値を生産します。メッセージのMIME本体で使用されるコンテントIDを引き出すために清潔なmsgイドをちびちび飲むのを囲む二重引用符を左右の角ブラケットに取り替えなければなりません。例えば

      Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example"
         indicates the token is in the body part containing

参照されています: 一口: r@ref.example;cid =" 2UWQFN309shb3@ref.example "は、ボディー部分含有には象徴があるのを示します。

           Content-ID: <2UWQFN309shb3@ref.example>

コンテントID: <2UWQFN309shb3@ref.example>。

   If the referrer-uri contains a comma, question mark, or semicolon,
   (for example, if it contains URI parameters) the URI MUST be enclosed
   in angle brackets (< and >). Any URI parameters are contained within
   these brackets. If the URI is not enclosed in angle brackets, any
   semicolon-delimited parameters are header-parameters, not URI
   parameters.

リファラー-uriがコンマ、疑問符、またはセミコロンを含んでいるなら、角ブラケット(<と>)に(例えばURIパラメタを含んでいるなら)URIを同封しなければなりません。どんなURIパラメタもこれらの括弧の中に含まれています。 URIが角ブラケットに同封されないなら、どんなセミコロンで区切られたパラメタもURIパラメタではなく、ヘッダーパラメタです。

   The Referred-By header field MAY appear in any SIP request, but is
   meaningless for ACK and CANCEL.  Proxies do not need to be able to
   read Referred-By header field values and MUST NOT remove or modify
   them.

近くReferredヘッダーフィールドは、どんなSIP要求にも現れるかもしれませんが、ACKとキャンセルに、無意味です。プロキシは、それらをヘッダーフィールド値を近くReferredに読み込む必要はないことができて、取り除いてはいけませんし、また変更してはいけません。

Sparks                      Standards Track                     [Page 6]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[6ページ]RFC3892をかきたてます。

   The following row should be interpreted as if it appeared in Table 3
   of RFC 3261.

以下の列はまるでRFC3261のTable3に現れるかのように解釈されるべきです。

     Header field              where       proxy ACK BYE CAN INV OPT REG
     ___________________________________________________________________
     Referred-By                 R                -   o   -   o   o   o

ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________________ 参照されたR(o)o o o

4.  The Referred-By Token

4. 参照された象徴

   The Referred-By token is an Authenticated Identity Body as defined by
   [3].  This body part MUST be identified with a MIME [6] Content-ID:
   field.

近くReferred象徴は[3]によって定義されるようにAuthenticated Identity Bodyです。この身体の部分をMIME[6]コンテントIDと同一視しなければなりません: さばきます。

   The sipfrag inside a Referred-By token MUST contain copies of the
   Refer-To, Referred-By, and Date header fields from the REFER request.

近くReferred象徴の中のsipfragがコピーを含まなければならない、Refer、-、近くReferred、およびREFER要求からのDateヘッダーフィールド。

   The token SHOULD NOT contain the Call-ID header field from the REFER
   request as that information is not useful to the refer target and may
   even be an information leak.  The token SHOULD NOT contain the From
   header field from the REFER request since the identity being claimed
   is represented in the Referred-By header field.

象徴SHOULD NOTがそれとしての情報が役に立たないREFER要求からのCall-IDヘッダーフィールドを含んでいる、目標を参照して、情報漏出になりさえするかもしれません。要求されるアイデンティティが近くReferredヘッダーフィールドで表されるので、象徴SHOULD NOTはREFER要求からのFromヘッダーフィールドを含んでいます。

   The token MAY contain the To header field from the REFER request, but
   it SHOULD NOT be included unless the referrer has cryptographically
   identified the referee.  Some ways this authentication can be
   achieved include inspecting the certificates used in a TLS
   association between the referrer and the referee or encrypting the
   Refer-To header in the REFER request using the S/MIME encryption
   techniques detailed in [5].

象徴はREFER要求からのToヘッダーフィールドを含むかもしれなくて、唯一のそれはSHOULD NOTです。リファラーが暗号でレフリーを特定していない場合、含まれています。この認証を達成できるいくつかの方法が、リファラーとレフリーとのTLS仲間で使用される証明書かコード化を点検するのを含んでいる、Refer、-、ヘッダー、[5]で詳細なS/MIME暗号化のテクニックを使用するREFER要求で。

   When inspecting the certificates used to establish TLS associations,
   the identity asserted in the token's To header field URI is compared
   to the subjectAltNames from the referee's certificate.  The sip and
   sips URI schemes MUST be treated as equivalent for this comparison.
   If the URI is an exact match, confidence in the authentication is
   high and the To header field MAY be added to the token.  If the
   certificate subjects contain only a hostname matching the hostname
   portion of the URI, an application level warning SHOULD be issued to
   the referrer agent's user seeking that user's consent before
   including the To header field in the token.

TLS協会を証明するのに使用される証明書を点検するとき、象徴のToヘッダーフィールドURIで断言されたアイデンティティはレフリーの証明書からsubjectAltNamesと比較されます。この比較のために一口と一口URI計画を同等物として扱わなければなりません。 URIが完全な一致であるなら、認証における信用は高いです、そして、Toヘッダーフィールドは象徴に加えられるかもしれません。証明書対象がURIのホスト名部分に合っているホスト名だけを含んでいるなら、SHOULDが象徴にToヘッダーフィールドを含む前にそのユーザの同意を求める予定であるリファラーエージェントのユーザに発行されると警告するアプリケーションレベルです。

   Including the To header field in the token significantly strengthens
   the claim being asserted by the token, but may have privacy
   implications as discussed in Section 6.1.

象徴にToヘッダーフィールドを含むのにおいて、象徴によって断言されるクレームをかなり強化しますが、プライバシー意味がセクション6.1で議論するようにあるかもしれません。

   Additional header fields and body parts MAY be included in the token.

追加ヘッダーフィールドと身体の部分は象徴に含まれるかもしれません。

Sparks                      Standards Track                     [Page 7]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[7ページ]RFC3892をかきたてます。

   As described in [3], a Referred-By token MAY be encrypted as well as
   signed.  The subjectAltName of the certificate used for these
   operations SHOULD exactly match the identity claimed in the
   referrer-uri in the Referred-By header field in the token.

説明されたコネ[3]として、近くReferred象徴は、コード化されて、サインされるかもしれません。 SHOULDがまさに合っているこれらの操作に使用される証明書のsubjectAltNameは中で近くReferredヘッダーのリファラーuriで象徴をさばきますアイデンティティが、主張した。

4.1.  Refer Target Inspection of a Referred-By Token

4.1. 参照された象徴の目標点検を参照してください。

   A refer target MUST treat a Referred-By token with an invalid
   signature as an invalid token.  A target SHOULD treat a token with an
   aged Date header field value as invalid.

Aは目標を参照します。無効の象徴として無効の署名で近くReferred象徴を扱わなければなりません。目標SHOULDは無効の老いているDateヘッダーフィールド同じくらい価値で象徴を扱います。

   A target SHOULD verify that the request it receives matches the
   reference in the Refer-To header field in the token.  This
   verification SHOULD include at least the request method and any
   indicated end-to-end header field values.  Note that the URI in the
   Refer-To header field may not match the request URI in the received
   request due to request re-targeting between the referee and the refer
   target.

A目標SHOULDが、それが受け取る要求が中で参照に合っていることを確かめる、Refer、-、象徴のヘッダーフィールド。この検証SHOULDは少なくとも要求方法と終わりから終わりへのヘッダーフィールドどんな示された値も含んでいます。そして、それに注意してください、中のURI、Refer、-、ヘッダーフィールドが間にレフリーを再狙いながら要求する容認された要求支払われるべきもので要求URIを合わせないかもしれない、目標を参照してください。

   The target SHOULD verify that the identity in the Referred-By header
   field in the token exactly matches the SubjectAltName from the
   signing certificate, reporting discrepancies to its user as described
   in [3].

目標SHOULDは、象徴の近くReferredヘッダーフィールドにおけるアイデンティティがまさに署名証明書からSubjectAltNameに合っていることを確かめます、[3]で説明されるように食い違いをユーザに報告して。

   If the token contains a To header field, the target SHOULD verify
   that the identity it expresses matches the referrer.  One way of
   verifying this is to exactly match the identity in the token's To
   header field with the subjectAltName of the certificate used by the
   referee to sign the aib protecting the request itself.  The 428
   response defined in [7] can be used to request such an aib if one is
   not already present.

象徴がToヘッダーフィールドを含んでいるなら、目標SHOULDは、それが言い表すアイデンティティがリファラーに合っていることを確かめます。これについて確かめる1つの方法はまさに要求自体を保護するaibにサインするのにレフリーによって使用される証明書のsubjectAltNameに象徴のToヘッダーフィールドにおけるアイデンティティを合わせることです。 1つが既に存在していないなら、そのようなaibを要求するのに[7]で定義された428応答は使用できます。

5.  The 429 Provide Referrer Identity Error Response

5. 429はリファラーアイデンティティ誤り応答を提供します。

   The 429 client error response code is used by a refer target to
   indicate that the referee must provide a valid Referred-By token.  As
   discussed in the behavior section, the referee will forward this
   error response to the referrer in a NOTIFY as the result of the
   REFER.  The suggested text phrase for the 429 error response is
   "Provide Referrer Identity".

使用される429クライアント誤り応答コードは、レフリーが有効な近くReferred象徴を提供しなければならないのを示すのにaで目標を参照します。振舞い部で議論するように、レフリーはREFERの結果としてNOTIFYのリファラーへのこの誤り応答を進めるでしょう。 429誤り応答のための提案されたテキスト句は「リファラーのアイデンティティを提供してください」です。

6.  Security Considerations

6. セキュリティ問題

   The mechanism defined in this specification relies on an intermediary
   (the referee) to forward information from the referrer to the refer
   target.  This necessarily establishes the referee as an eavesdropper
   of that information and positions him perfectly to launch man-in-
   the-middle attacks using the mechanism.

この仕様に基づき定義されたメカニズムがリファラーからの情報を転送する仲介者(レフリー)に頼る、目標を参照してください。これが必ずその情報の立ち聞きする者とレフリーを書き立てて、中の男性を送り出すために彼を完全に置く、-、-、中央、メカニズムを使用する攻撃。

Sparks                      Standards Track                     [Page 8]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[8ページ]RFC3892をかきたてます。

   A SIP proxy is similarly positioned.  Protecting SIP messaging from
   malicious proxy implementations is discussed in [5].  In contrast to
   a proxy,  the referee's agent is an endpoint.  Proxies will typically
   be managed and monitored by service providers.  Malicious behavior by
   a proxy is more likely to be noticed and result in negative
   repercussions for the provider than malicious behavior by an endpoint
   would be.  The behavior of an endpoint can be entirely under the
   control of a single user.  Thus, it is more feasible for an endpoint
   acting as referee to behave maliciously than it is for a proxy being
   operated by a service provider.

SIPプロキシは同様に置かれます。 [5]で悪意があるプロキシ実現からSIPメッセージングを保護するのと議論します。対照的に、プロキシ、レフリーのエージェントには、終点があります。プロキシは、サービスプロバイダーによって通常管理されて、モニターされるでしょう。プロキシによる悪意のある態度は、気付かれていて、終点のそばでの悪意のある態度であるだろうよりプロバイダーのための悪影響をもたらしそうです。終点の振舞いが完全にシングルユーザーのコントロールの下にあることができます。したがって、陰湿に振る舞うためにレフェリーを務める終点には、それがサービスプロバイダーによって手術されているプロキシのためにそれより可能です。

   This specification uses an S/MIME based mechanism to enable the refer
   target to detect manipulation of the Referred-By information by the
   referee.  Use of this protection is optional!  The community has
   asserted that there are systems where trust in the validity of this
   information is either not important or can be established through
   other means.  Any implementation choosing not to use this optional
   mechanism needs to provide its own defense to the following risks:

この仕様が可能にするS/MIMEのベースのメカニズムを使用する、レフリーによる近くReferred情報の操作を検出するのに目標を参照してください。この保護の使用は任意です! 共同体は、システムがこの情報の正当性への信用を重要でないか、または他の手段で確立できるところにあると断言しました。この任意のメカニズムを使用しないのを選ぶどんな実現も、それ自身のディフェンスを以下のリスクに提供する必要があります:

   o  The Referred-By information is highly likely to influence request
      admission policy.  For instance, it may be displayed to the user
      of the agent with a "This call was transferred to you by X.
      Accept?" prompt.  A malicious referee can unduly influence that
      policy decision by providing falsified referred-by information.
      This includes falsely claiming to have been referred in the first
      place.  (The S/MIME mechanism protects the information with a
      signature, hampering the referee's ability to inject or modify
      information without knowing the key used for that signature.)

o 近くReferred情報は要求入場方針に非常に影響を及ぼしそうです。例えば、「この呼び出しはX.Accept?によってあなたに移された」プロンプトと共にエージェントのユーザにそれを表示するかもしれません。改竄された参照された情報を提供することによって、悪意があるレフリーはその政策決定に過度に影響を及ぼすことができます。これは、第一に参照されたと間違って主張するのを含んでいます。 (S/MIMEメカニズムは署名で情報を保護します、その署名に使用されるキーを知らないで情報を注入するか、または変更するレフリーの能力を妨げて。)

   o  A referee is by definition an eavesdropper of the referred-by
      information.  Parts of that information may be sensitive.  (The
      S/MIME mechanism allows encryption.)

o レフリーは定義上参照された情報の立ち聞きする者です。その情報の部分は敏感であるかもしれません。 (S/MIMEメカニズムは暗号化を許容します。)

   o  The referee may store any referred-by information it sees and
      paste it into future unrelated requests.  (The S/MIME mechanism
      allows detection of stale assertions by covering a timestamp with
      the signature and allows detection of use in unrelated requests by
      covering the Refer-To header field with the signature.)

o レフリーは、それが見るどんな参照された情報も格納して、今後の関係ない要求にそれを貼るかもしれません。 (S/MIMEメカニズムが署名でタイムスタンプをカバーすることによって聞き古した主張の検出を許して、覆いで関係ない要求で役に立つ検出を許す、Refer、-、署名があるヘッダーフィールド)。

   The mechanisms in this specification do NOT prevent the referee from
   deleting ALL referred-by information from the referenced request.  A
   refer target can not detect such deletion.  This introduces no new
   problems since removing all referred-by information from a referenced
   request transforms it into an ordinary SIP request as described in
   [5].  Thus the referee gains no new influence over processing logic
   at the refer target by removing the referred-by information.

この仕様によるメカニズムは、レフリーが参照をつけられた要求からすべての参照された情報を削除するのを防ぎません。 Aは目標を参照します。そのような削除を検出できません。これは以来参照をつけられた要求からすべての参照された情報を取り除くとそれが[5]で説明されるように普通のSIP要求に変えられることにおけるどんな新しい問題も紹介しません。このようにして、レフリーが処理論理へのどんな新しい影響も獲得しない、参照された情報を取り除くことによって、目標を示してください。

Sparks                      Standards Track                     [Page 9]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[9ページ]RFC3892をかきたてます。

   Refer targets can protect themselves from the possibility of a
   malicious referee removing a token (leaving an unsecured identity in
   the Referred-By header field) by using the 429 error response.

悪意があるレフリーが429誤り応答を使用することによって象徴(近くReferredヘッダーフィールドにおける非安全にされたアイデンティティを残す)を取り外す可能性から缶が保護する目標を自分たちで、参照してください。

   Applications using the mechanisms in this document may be able to
   take advantage of pre-existing relationships between the participants
   to mitigate the risks of its use.  In some transfer scenarios, A has
   the choice of referring B to C or referring C to B.  If A and B have
   a pre-existing trust relationship, leading A to have greater
   confidence that B will not behave maliciously (B is A's
   administrative assistant for example), referring B to C may make more
   sense.

メカニズムを使用するアプリケーションは本書では使用の危険を緩和する関係者の間の関係を先在させる利点を活用できるかもしれません。いくつかの転送シナリオでは、BからCを参照するか、またはB.If AとBをCを参照することの選択はAで先在の信用関係を持っています、AにはBが陰湿に振る舞わないで(例えば、BはAのゼネラルスタッフです)、BからCを参照するのが、より多く理解できるかもしれないというよりすごい信用があるように導いて。

   This mechanism involves two SIP requests between three endpoints, the
   REFER and the referenced request.  The content of those messages
   (including the referred-by information) is subject to the security
   considerations and protection mechanisms documented in [5].

このメカニズムは3つの終点と、REFERと参照をつけられた要求の間の2つのSIP要求にかかわります。それらのメッセージ(参照された情報を含んでいる)の内容は[5]に記録されたセキュリティ問題と保護メカニズムを受けることがあります。

   Proxies between the participants may collect referred-by information
   and re-insert it in future requests or make it available to hostile
   endpoints.  The end-to-end confidentiality capabilities discussed in
   [5] can help reduce the risk of exposing sensitive referred-by
   information to these proxies.  The abuse possibilities in subsequent
   requests by proxies (or endpoints that they may leak information to)
   between the referee and the refer target are identical to the abuse
   by the referee, and the considerations discussed for a malicious
   referee applies.  The abuse possibilities in subsequent requests by
   proxies (or endpoints that they may leak information to) between the
   referrer and the referee are similar to those discussed for the
   presentation of Authenticated Identity Bodies in [7].

関係者の間のプロキシは、参照された情報とそれがこれから要求する再挿入を集めるか、またはそれを敵対的な終点に利用可能にするかもしれません。終わりから終わりへの秘密性[5]で議論した能力は、機密の参照された情報をこれらのプロキシに露出するという危険を減少させるのを助けることができます。参照してください。そして、レフリーの間のプロキシ(または、それらが情報を漏らすかもしれない終点)によるその後の要求における乱用の可能性、悪意があるレフリーが適用するので、目標はレフリー、および議論した問題で乱用と同じです。リファラーとレフリーの間のプロキシ(または、それらが情報を漏らすかもしれない終点)によるその後の要求における乱用の可能性は[7]のAuthenticated Identity Bodiesのプレゼンテーションのために議論したものと同様です。

6.1.  Identifying the Referee in the Referred-by Token

6.1. 参照された象徴でレフリーを特定します。

   To a refer target, a Referred-By token minimally asserts "The
   identity expressed by this Referred-By header field asked at the time
   indicated in this Date header field that the request indicated by
   this Refer-To header field be sent".  This assertion makes no claims
   at all about who is being asked to send the request.  This is
   sufficient to enable policies such as "Accept any requests referred
   by Alice", but not "Only accept requests from Bob if he can prove
   that Alice referred him to us".  Thus, there is an opportunity for a
   cut-and-paste attack.  If Mallory sees Alice refer Carol to us using
   a minimal token, he can copy that token into his own request (as long
   as it matches what is indicated in the embedded Refer-To header), and
   it will appear to us that Alice referred Mallory to us.  This risk is
   best mitigated by protecting the REFER Alice sends to Carol from
   eavesdropping, using TLS or the S/MIME mechanisms detailed in [5].

aに、目標を参照してください、と近くReferred象徴が最少量で断言する、「この近くReferredヘッダーフィールドによって言い表されたアイデンティティが要求がこれで示したこのDateヘッダーフィールドで示された時に尋ねた、Refer、-、ヘッダーフィールド、送ってください、」この主張はだれが要求を送るように頼まれるかに関して全くノークレームをします。これは、「彼が、アリスが彼を私たちに差し向けたと立証できるなら、ボブから要求を単に受け入れてください」ではなく「アリスによって参照されたあらゆる要求を受け入れてください」などの方針を可能にするために十分です。したがって、カットアンドペースト攻撃の機会があります。中に示されることを合わせる限り、Malloryが、アリスが最小量の象徴を使用することでキャロルを私たちに差し向けるのを見るなら、彼が彼自身の要求にその象徴をコピーできる、(埋め込み、Refer、-、ヘッダー、)、私たちにとって、アリスが私たちにMalloryについて照会したように見えるでしょう。アリスが雨垂れからキャロルに送るREFERを保護することによってこの危険を緩和するのが最も良い、TLSか[5]で詳細なS/MIMEメカニズムを使用して。

Sparks                      Standards Track                    [Page 10]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[10ページ]RFC3892をかきたてます。

   Including the To header field from the REFER request in the
   Referred-by token enables the "Only accept requests from Bob if he
   can prove that Alice referred him to us".  Alice is constrained to
   add this header to the token only if she is sure she is sending the
   REFER request to Bob.  We, in turn, ensure it was Bob that sent the
   referenced request to us, in addition to validating Alice's signature
   of the token.  Mallory's earlier attack is not effective with this
   token.

近くReferred象徴でのREFER要求からのToヘッダーフィールドを含んでいると、「彼が、アリスが彼を私たちに差し向けたと立証できるなら、ボブから要求を単に受け入れてください」は可能にされます。彼女がREFER要求をボブに送るのを確信している場合にだけ、アリスがこのヘッダーを象徴に加えるのが抑制されます。私たちは、参照をつけられた要求を私たちに送ったのが、ボブであったのを順番に保証します、アリスの象徴の署名を有効にすることに加えて。マロリー・ワイス症候群の以前の攻撃はこの象徴によって有効ではありません。

   Including the To header field in the Referred-By token has privacy
   implications, however.  Carol, above, might wish to contact us
   anonymously.  That wish would be defeated if Carol's identity
   appeared in the token Alice created.  If Alice encrypted the token to
   us, Carol will not even be aware of the information leak.  To protect
   herself when she wishes anonymity, Carol will have to reject any
   REFER requests containing a Referred-By token she can not inspect.

しかしながら、近くReferred象徴にToヘッダーフィールドを含むのにおいて、プライバシー意味があります。キャロルは上で匿名で私たちに連絡したがっているかもしれません。キャロルのアイデンティティがアリスが作成した象徴に現れるなら、その願望は破られるでしょうに。アリスが象徴を私たちにコード化したなら、キャロルは情報漏出を意識さえしないでしょう。彼女が匿名を願っているとき、我が身をかばうために、キャロルは彼女が点検できない近くReferred象徴を含むどんなREFER要求も拒絶しなければならないでしょう。

7.  Examples

7. 例

7.1.  Basic REFER

7.1. 基礎は参照されます。

   This example shows the secured Referred-By mechanism applied to a
   REFER to an SIP INVITE URI.

この例は、安全にされた近くReferredメカニズムがSIP INVITE URIへのREFERに適用されたのを示します。

   Details are shown only for those messages involved in exercising the
   mechanism defined in this document.

詳細は本書では定義されたメカニズムを運動させるのにかかわるそれらのメッセージのためだけに示されます。

   Referrer                    Referee                   Refer Target
      | F1 REFER                  |                            |
      |-------------------------->|                            |
      | 202 Accepted              |                            |
      |<--------------------------|                            |
      | NOTIFY                    |                            |
      |<--------------------------| F2 INVITE                  |
      | 200 OK                    |--------------------------->|
      |-------------------------->| 200 OK                     |
      |                           |<---------------------------|
      |                           | ACK                        |
      | NOTIFY                    |--------------------------->|
      |<--------------------------|                            |
      | 200 OK                    |                            |
      |-------------------------->|                            |
      |                           |                            |

Sparks                      Standards Track                    [Page 11]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[11ページ]RFC3892をかきたてます。

   F1 REFER sip:referee@referee.example SIP/2.0
      Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
      To: sip:referee@referee.example
      From: sip:referrer@referrer.example;tag=39092342
      Call-ID: 2203900ef0299349d9209f023a
      CSeq: 1239930 REFER
      Max-Forwards: 70
      Contact: <sip:referrer.example>
      Refer-To: <sip:refertarget@target.example>
      Referred-By: <sip:referrer@referrer.example>
         ;cid="20398823.2UWQFN309shb3@referrer.example"
      Content-Type: multipart/mixed; boundary=unique-boundary-1
      Content-Length: (appropriate value)

F1 REFER一口: referee@referee.example SIP/2.0Via: 一口/2.0/UDP referrer.example; ブランチ=z9hG4bK392039842To: 一口: referee@referee.example From: 一口: referrer@referrer.example;tag =39092342Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 前方へマックスを参照してください: 70 接触: <はTo:を参照する状態で: referrer.example>をちびちび飲みます。 <一口: refertarget@target.example 、gt;、参照されています: <一口: referrer@referrer.example 、gt;、; Cidは" 20398823.2UWQFN309shb3@referrer.example "コンテントタイプと等しいです: 複合か混ぜられる。境界はユニークな境界-1のContent-長さと等しいです: (適切な値)

      --unique-boundary-1
      Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=dragons39
      Content-ID: <20398823.2UWQFN309shb3@referrer.example>
      Content-Length: (appropriate value)

--ユニークな境界1コンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。境界はdragons39コンテントIDと等しいです: <20398823.2UWQFN309shb3@referrer.example>コンテンツの長さ: (適切な値)

      --dragons39
      Content-Type: message/sipfrag
      Content-Disposition: aib; handling=optional

--dragons39コンテントタイプ: sipfrag Contentメッセージ/気質: aib。取り扱い=任意です。

      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Refer-To: <sip:refertarget@target.example>
      Referred-By: <sip:referrer@referrer.example>
         ;cid="20398823.2UWQFN309shb3@referrer.example"

日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒、To:を参照します。 <一口: refertarget@target.example 、gt;、参照されています: <一口: referrer@referrer.example 、gt;、;Cidが" 20398823.2UWQFN309shb3@referrer.example "と等しい

      --dragons39
      Content-Type: application/pkcs7-signature; name=smime.p7s
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7s;
         handling=required

--dragons39コンテントタイプ: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。ファイル名はsmime.p7sと等しいです。取り扱いが=必要です。

      (appropriate signature goes here)

(適切な署名はここに行きます)

      --dragons39--
      --unique-boundary-1--

--dragons39----ユニークな境界-1--

   F2 INVITE sip:refertarget@target.example SIP/2.0
      Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
      To: <sip:refertarget@target.example>
      From: <sip:referee@referee.example>;tag=2909034023
      Call-ID: fe9023940-a3465@referee.example
      CSeq: 889823409 INVITE
      Max-Forwards: 70

Sparks                      Standards Track                    [Page 12]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[12ページ]RFC3892をかきたてます。

      Contact: <sip:referee@referee.example>
      Referred-By: <sip:referrer@referrer.example>
         ;cid="20398823.2UWQFN309shb3@referrer.example"
      Content-Type: multipart/mixed; boundary=my-boundary-9
      Content-Length: (appropriate value)

接触: <一口: referee@referee.example 、gt;、参照されています: <一口: referrer@referrer.example 、gt;、; Cidは" 20398823.2UWQFN309shb3@referrer.example "コンテントタイプと等しいです: 複合か混ぜられる。境界=、私、-、境界-9のContent-長さ: (適切な値)

      --my-boundary-9
      Content-Type: application/sdp
      Content-Length: (appropriate value)

--私の境界9コンテントタイプ: sdp Contentアプリケーション/長さ: (適切な値)

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

0 0INセッションレフリー2890844526 2890844526IN v=0o=IP4 referee.example s=SDP c=IP4 referee.example t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000

      --my-boundary-9
      Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=dragons39
      Content-ID: <20398823.2UWQFN309shb3@referrer.example>
      Content-Length: (appropriate value)

--私の境界9コンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。境界はdragons39コンテントIDと等しいです: <20398823.2UWQFN309shb3@referrer.example>コンテンツの長さ: (適切な値)

      --dragons39
      Content-Type: message/sipfrag
      Content-Disposition: aib; handling=optional

--dragons39コンテントタイプ: sipfrag Contentメッセージ/気質: aib。取り扱い=任意です。

      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Refer-To: <sip:refertarget@target.example>
      Referred-By: <sip:referrer@referrer.example>
         ;cid="20398823.2UWQFN309shb3@referrer.example"

      --dragons39
      Content-Type: application/pkcs7-signature; name=smime.p7s
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7s;
         handling=required

      (appropriate signature goes here)

(適切な署名はここに行きます)

      --dragons39--
      --my-boundary-9--

--dragons39--、--、私、-、境界-9--

Sparks                      Standards Track                    [Page 13]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[13ページ]RFC3892をかきたてます。

7.2.  Insecure REFER

7.2. 不安定である、参照

   The flow for this example is the same as that of Section 7.1.  Here,
   the referrer has opted to not include a Referred-By token, and the
   refer target is willing to accept the referenced request without one.

この例のための流れはセクション7.1のものと同じです。参照してください。そして、ここで、リファラーが近くReferred象徴を含まないように選ばれた、目標は、1なしで参照をつけられた要求を受け入れても構わないと思っています。

   F1 REFER sip:referee@referee.example SIP/2.0
      Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
      To: <sip:referee@referee.example>
      From: <sip:referrer@referrer.example>;tag=39092342
      Call-ID: 2203900ef0299349d9209f023a
      CSeq: 1239930 REFER
      Max-Forwards: 70
      Contact: <sip:referrer.example>
      Refer-To: <sip:refertarget@target.example>
      Referred-By: <sip:referrer@referrer.example>
      Content-Length: 0

F1 REFER一口: referee@referee.example SIP/2.0Via: 一口/2.0/UDP referrer.example; ブランチ=z9hG4bK392039842To: <一口: referee@referee.example 、gt;、From: <一口: referrer@referrer.example 、gt;、; タグは39092342呼び出しIDと等しいです: 2203900ef0299349d9209f023a CSeq: 1239930 前方へマックスを参照してください: 70 接触: <はTo:を参照する状態で: referrer.example>をちびちび飲みます。 <一口: refertarget@target.example 、gt;、参照されています: <一口: referrer@referrer.example 、gt;、コンテンツの長さ: 0

   F2 INVITE sip:refertarget@target.example SIP/2.0
      Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
      To: <sip:refertarget@target.example>
      From: <sip:referee@referee.example>;tag=2909034023
      Call-ID: fe9023940-a3465@referee.example
      CSeq: 889823409 INVITE
      Max-Forwards: 70
      Contact: <sip:referee@referee.example>
      Referred-By: <sip:referrer@referrer.example>
      Content-Type: application/sdp
      Content-Length: (appropriate value)

F2 INVITE一口: refertarget@target.example SIP/2.0Via: 一口/2.0/UDP referee.example; ブランチ=z9hG4bKffe209934aac To: <一口: refertarget@target.example 、gt;、From: <一口: referee@referee.example 、gt;、; タグは2909034023呼び出しIDと等しいです: fe9023940-a3465@referee.example CSeq: 889823409 前方へマックスを招待してください: 70 接触: <一口: referee@referee.example 、gt;、参照されています: <一口: referrer@referrer.example 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: (適切な値)

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

0 0INセッションレフリー2890844526 2890844526IN v=0o=IP4 referee.example s=SDP c=IP4 referee.example t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000

7.3.  Requiring Referrer Identity

7.3. リファラーのアイデンティティを必要とします。

   In contrast to the example in Section 7.2, the refer target requires
   a Referred-By token to accept the referenced request.  The referrer
   chooses to provide an encrypted token (note that the block surrounded
   by asterisks represents encrypted content).  F1 and F2 are identical
   to the messages detailed in Section 7.2.

目標を参照してください。セクション7.2の例と対照して必要である、参照をつけられた要求を受け入れるために近くReferred象徴を必要とします。リファラーは、コード化された象徴を提供するのを選びます(アスタリスクによって囲まれたブロックがコード化された内容を表すことに注意してください)。 F1とF2はセクション7.2で詳細なメッセージと同じです。

Sparks                      Standards Track                    [Page 14]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[14ページ]RFC3892をかきたてます。

   Referrer                    Referee                   Refer Target
      | F1 REFER                  |                            |
      |-------------------------->|                            |
      | 202 Accepted              |                            |
      |<--------------------------|                            |
      | NOTIFY                    |                            |
      |<--------------------------| F2 INVITE                  |
      | 200 OK                    |--------------------------->|
      |-------------------------->| F3 429 Provide Referrer Identity
      |                           |<---------------------------|
      |                           | ACK                        |
      | F4 NOTIFY                 |--------------------------->|
      |<--------------------------|                            |
      | 200 OK                    |                            |
      |-------------------------->|                            |
      | F5 REFER                  |                            |
      |-------------------------->|                            |
      | 202 Accepted              |                            |
      |<--------------------------|                            |
      | NOTIFY                    |                            |
      |<--------------------------| F6 INVITE                  |
      | 200 OK                    |--------------------------->|
      |-------------------------->| 200 OK                     |
      |                           |<---------------------------|
      |                           | ACK                        |
      | NOTIFY                    |--------------------------->|
      |<--------------------------|                            |
      | 200 OK                    |                            |
      |-------------------------->|                            |
      |                           |                            |

リファラーレフリーは目標を参照します。| F1は参照されます。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 202は受け入れました。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| F2招待| | 200 OK|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| F3 429はリファラーのアイデンティティを提供します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ACK| | F4は通知します。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| F5は参照します。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 202は受け入れました。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| F6招待| | 200 OK|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ACK| | 通知してください。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK| | |-------------------------->| | | | |

   F3 SIP/2.0 429 Provide Referrer Identity
      Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
      To: <sip:refertarget@target.example>;tag=392093422302334
      From: <sip:referee@referee.example>;tag=2909034023
      Call-ID: fe9023940-a3465@referee.example
      CSeq: 889823409 INVITE
      Content-Length: 0

F3一口/2.0 429は以下を通ってリファラーのアイデンティティを提供します。一口/2.0/UDP referee.example; ブランチ=z9hG4bKffe209934aac To: <一口: refertarget@target.example 、gt;、;=392093422302334From:にタグ付けをしてください <一口: referee@referee.example 、gt;、; タグは2909034023呼び出しIDと等しいです: fe9023940-a3465@referee.example CSeq: 889823409 コンテンツの長さを招待してください: 0

Sparks                      Standards Track                    [Page 15]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[15ページ]RFC3892をかきたてます。

   F4 NOTIFY sip:referrer@referrer.example SIP/2.0
      Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390
      To: <sip:referrer@referrer.example>;tag=39092342
      From: <sip:referee@referee.example>;tag=199949923
      Call-ID: 2203900ef0299349d9209f023a
      CSeq: 3920390 NOTIFY
      Event: refer;id=1239930
      Subscription-State: terminated
      Content-Type: message/sipfrag
      Content-Length: (appropriate value)

F4 NOTIFY一口: referrer@referrer.example SIP/2.0Via: 一口/2.0/UDP referee.example; ブランチ=z9hG4bK2934209da390To: <一口: referrer@referrer.example 、gt;、;=39092342From:にタグ付けをしてください <一口: referee@referee.example 、gt;、; タグは199949923呼び出しIDと等しいです: 2203900ef0299349d9209f023a CSeq: 3920390 出来事に通知してください: 参照してください; イドは1239930Subscription-状態と等しいです: 終えられたコンテントタイプ: sipfrag Contentメッセージ/長さ: (適切な値)

      SIP/2.0 429 Provide Referrer Identity

一口/2.0 429はリファラーのアイデンティティを提供します。

   F5 REFER sip:referee@referee.example SIP/2.0
      Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423
      To: <sip:referee@referee.example>
      From: <sip:referrer@referrer.example>;tag=39092342
      Call-ID: 2203900ef0299349d9209f023a
      CSeq: 1239931 REFER
      Max-Forwards: 70
      Contact: <sip:referrer.example>
      Refer-To: <sip:refertarget@target.example>
      Referred-By: <sip:referrer@referrer.example>
         ;cid="20342EFXEI.390sdefn2@referrer.example"
      Content-Type: multipart/mixed; boundary=unique-boundary-1
      Content-Length: (appropriate value)

F5 REFER一口: referee@referee.example SIP/2.0Via: 一口/2.0/UDP referrer.example; ブランチ=z9hG4bK98823423To: <一口: referee@referee.example 、gt;、From: <一口: referrer@referrer.example 、gt;、; タグは39092342呼び出しIDと等しいです: 2203900ef0299349d9209f023a CSeq: 1239931 前方へマックスを参照してください: 70 接触: <はTo:を参照する状態で: referrer.example>をちびちび飲みます。 <一口: refertarget@target.example 、gt;、参照されています: <一口: referrer@referrer.example 、gt;、; Cidは" 20342EFXEI.390sdefn2@referrer.example "コンテントタイプと等しいです: 複合か混ぜられる。境界はユニークな境界-1のContent-長さと等しいです: (適切な値)

      --unique-boundary-1
      Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=boundary42
      Content-ID: <20342EFXEI.390sdefn2@referrer.example>
      Content-Length: (appropriate value)

--ユニークな境界1コンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。境界はboundary42コンテントIDと等しいです: <20342EFXEI.390sdefn2@referrer.example>コンテンツの長さ: (適切な値)

      --boundary42
      Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
        name=smime.p7m
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7m;
        handling=required
      Content-Length: (appropriate value)

--boundary42コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプはおおわれたデータと等しいです。 =smime.p7m Content-転送コード化を命名してください: base64 Content-気質: 付属。ファイル名はsmime.p7mと等しいです。取り扱いは=Content-長さを必要としました: (適切な値)

Sparks                      Standards Track                    [Page 16]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[16ページ]RFC3892をかきたてます。

      ***********************************************************
      * Content-Type: message/sipfrag                           *
      * Content-Disposition: aib; handling=optional             *
      *                                                         *
      * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
      * Refer-To: <sip:refertarget@target.example>              *
      * Referred-By: <sip:referrer@referrer.example>            *
      *    ;cid="20342EFXEI.390sdefn2@referrer.example"         *
      ***********************************************************

*********************************************************** * コンテントタイプ: sipfrag**満足しているメッセージ/気質: aib。任意の*取り扱い=***日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒**、To:を参照します。 <一口: refertarget@target.example 、gt;、**は参照されました: 一口..Cid

      --boundary42
      Content-Type: application/pkcs7-signature; name=smime.p7s
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7s;
         handling=required

--boundary42コンテントタイプ: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。ファイル名はsmime.p7sと等しいです。取り扱いが=必要です。

      (appropriate signature)

(適切な署名)

      --boundary42--

--boundary42--

   F6 INVITE sip:refertarget@target.example SIP/2.0
      Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423
      To: <sip:refertarget@target.example>
      From: <sip:referee@referee.example>;tag=1342093482342
      Call-ID: 23499234-9239842993@referee.example
      CSeq: 19309423 INVITE
      Max-Forwards: 70
      Referred-By: <sip:referrer@referrer.example>
         ;cid="20342EFXEI.390sdefn2@referrer.example"
      Contact: <sip:referee@referee.example>
      Content-Type: multipart/mixed; boundary=my-boundary-9
      Content-Length: (appropriate value)

F6 INVITE一口: refertarget@target.example SIP/2.0Via: 一口/2.0/UDP referee.example; ブランチ=z9hG4bK3920390423To: <一口: refertarget@target.example 、gt;、From: <一口: referee@referee.example 、gt;、; タグは1342093482342呼び出しIDと等しいです: 23499234-9239842993@referee.example CSeq: 19309423 前方へマックスを招待してください: 70 参照されています: <一口: referrer@referrer.example 、gt;、; Cidは" 20342EFXEI.390sdefn2@referrer.example "接触と等しいです: <一口: referee@referee.example 、gt;、コンテントタイプ: 複合か混ぜられる。境界=、私、-、境界-9のContent-長さ: (適切な値)

      --my-boundary-9
      Content-Type: application/sdp
      Content-Length: (appropriate value)

--私の境界9コンテントタイプ: sdp Contentアプリケーション/長さ: (適切な値)

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

0 0INセッションレフリー2890844526 2890844526IN v=0o=IP4 referee.example s=SDP c=IP4 referee.example t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000

Sparks                      Standards Track                    [Page 17]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[17ページ]RFC3892をかきたてます。

      --my-boundary-9
      Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=boundary42
      Content-ID: <20342EFXEI.390sdefn2@referrer.example>
      Content-Length: (appropriate value)

--私の境界9コンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。境界はboundary42コンテントIDと等しいです: <20342EFXEI.390sdefn2@referrer.example>コンテンツの長さ: (適切な値)

      --boundary42
      Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
        name=smime.p7m
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7m;
        handling=required
      Content-Length: (appropriate value)

      ***********************************************************
      * Content-Type: message/sipfrag                           *
      * Content-Disposition: aib; handling=optional             *
      *                                                         *
      * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
      * Refer-To: <sip:refertarget@target.example>              *
      * Referred-By: <sip:referrer@referrer.example>            *
      *    ;cid="20342EFXEI.390sdefn2@referrer.example"         *
      ***********************************************************

      --boundary42
      Content-Type: application/pkcs7-signature; name=smime.p7s
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7s;
         handling=required

      (appropriate signature)

(適切な署名)

      --boundary42--
      --my-boundary-9--

--boundary42--、--、私、-、境界-9--

7.4.  Nested REFER

7.4. 入れ子にされて、参照してください。

   The Refer-To URI may be a SIP URI indicating the REFER method.
   Consider The following URI which A uses to refer B to send a REFER
   request to C which refers C to send an INVITE to D.

Refer、-、URIはREFER方法を示すSIP URIであるかもしれません。 Aが使用する次のURIがINVITEをDに送るのにCを参照するCにREFER要求を送るのにBを参照すると考えてください。

   Note that A provides a Referred-By token which gets passed through B
   and C to D.  In particular, B does not provide its own Referred-By
   token to C.  Also note that A is notified of the outcome of the
   request it triggered at B (the REFER), not at C (the INVITE).

AがBとCをD.In事項に通り抜ける近くReferred象徴を提供するというメモ、BはAがそれがC(INVITE)で引き金となったのではなく、B(REFER)で引き金となった要求の結果について通知されるというC.Alsoメモにそれ自身の近くReferred象徴を供給しません。

      Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">

To:を参照します。 <一口: C.の例; =が参照する方法--が=について言及する、「<一口: >">"というD.の例

Sparks                      Standards Track                    [Page 18]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[18ページ]RFC3892をかきたてます。

   This reference would result in the following flow:

この参照は以下の流れをもたらすでしょう:

  A                   B                   C                   D
  | F1 REFER          |                   |                   |
  |------------------>|                   |                   |
  | 202 Accepted      |                   |                   |
  |<------------------|                   |                   |
  | NOTIFY            |                   |                   |
  |<------------------| F2 REFER          |                   |
  | 200 OK            |------------------>|                   |
  |------------------>| 202 Accepted      |                   |
  | F3 NOTIFY         |<------------------|                   |
  |<------------------| NOTIFY            |                   |
  | 200 OK            |<------------------| F4 INVITE         |
  |------------------>| 200 OK            |------------------>|
  |                   |------------------>| 200 OK            |
  |                   | NOTIFY            |<------------------|
  |                   |<------------------| ACK               |
  |                   | 200 OK            |------------------>|
  |                   |------------------>|                   |
  |                   |                   |                   |

B C D| F1は参照されます。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 202は受け入れました。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| F2は参照します。| | | 200 OK|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 202は受け入れました。| | | F3は通知します。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 通知してください。| | | 200 OK| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| F4招待| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK| | | 通知してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| ACK| | | 200 OK|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|

  F1 REFER sip:B SIP/2.0
     Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
     To: <sip:B.example>
     From: <sip:A.example>;tag=23490234
     Call-ID: 2304098023@A.example
     CSeq: 2342093 REFER
     Max-Forwards: 70
     Contact: <sip:A.example>
     Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D>.example">
     Referred-By: <sip:A.example>;
         cid="23094202342.10123091233@A.example"
     Content-Type: multipart/mixed; boundary=unique-boundary-1
     Content-Length: (appropriate value)

F1は一口を参照します: 以下を通ってB一口/2.0 一口/2.0/UDP A.の例; ブランチ=z9hG4bK3802394232To: <一口: B.例の>From: <一口: A.の例の>; =23490234呼び出しIDにタグ付けをしてください: 2304098023@A.example CSeq: 2342093 前方へマックスを参照してください: 70 接触: <はTo:を参照する状態で: A.の例の>をちびちび飲みます。 <は: D>.exampleをちびちび飲みます。<一口: C.の例; =が参照する方法--が=について言及する、「「>は参照しました」。 <一口: A.の例の>。 Cidは" 23094202342.10123091233@A.example "コンテントタイプと等しいです: 複合か混ぜられる。境界はユニークな境界-1のContent-長さと等しいです: (適切な値)

     --unique-boundary-1
     Content-Type: multipart/signed;
       protocol="application/pkcs7-signature";
       micalg=sha1; boundary=dragons39
     Content-ID: <23094202342.10123091233@A.example>
     Content-Length: (appropriate value)

--ユニークな境界1コンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。境界はdragons39コンテントIDと等しいです: <23094202342.10123091233@A.例の>コンテンツの長さ: (適切な値)

     --dragons39
     Content-Type: message/sipfrag
     Content-Disposition: aib; handling=optional

--dragons39コンテントタイプ: sipfrag Contentメッセージ/気質: aib。取り扱い=任意です。

Sparks                      Standards Track                    [Page 19]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[19ページ]RFC3892をかきたてます。

     Date: Thu, 21 Feb 2002 13:02:03 GMT
     Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
     Referred-By: <sip:A.example>;
         cid="23094202342.10123091233@A.example"

日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒、To:を参照します。 <一口: C.の例; =が参照する方法--が=について言及する、「「>は参照した」という<一口: D.の例の>。 <一口: A.の例の>。 Cidは" 23094202342.10123091233@A.example "と等しいです。

     --dragons39
     Content-Type: application/pkcs7-signature; name=smime.p7s
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment; filename=smime.p7s;
        handling=required

     (appropriate signature goes here)

(適切な署名はここに行きます)

     --dragons39--
     --unique-boundary-1--

--dragons39----ユニークな境界-1--

  F2 REFER sip:C.example SIP/2.0
     Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842
     To: <sip:C.example>
     From: <sip:B.example>;tag=2934u23
     Call-ID: 203942834@B.example
     CSeq: 8321039 REFER
     Max-Forwards: 70
     Contact: <sip:B.example>
     Refer-To: <sip:D.example>
     Referred-By: <sip:A.example>;
         cid="23094202342.10123091233@A.example"
     Content-Type: multipart/mixed; boundary=unique-boundary-1
     Content-Length: (appropriate value)

F2は一口を参照します: 以下を通ってC.例一口/2.0 一口/2.0/UDP B.の例; ブランチ=z9hG4bK00239842To: <一口: C.例の>From: <一口: B.の例の>; =2934u23呼び出しIDにタグ付けをしてください: 203942834@B.example CSeq: 8321039 前方へマックスを参照してください: 70 接触: <はTo:を参照する状態で: B.の例の>をちびちび飲みます。 <は参照されていた状態で: D.の例の>をちびちび飲みます: <一口: A.の例の>。 Cidは" 23094202342.10123091233@A.example "コンテントタイプと等しいです: 複合か混ぜられる。境界はユニークな境界-1のContent-長さと等しいです: (適切な値)

     --unique-boundary-1
     Content-Type: multipart/signed;
       protocol="application/pkcs7-signature";
       micalg=sha1; boundary=dragons39
     Content-ID: <23094202342.10123091233@A.example>
     Content-Length: (appropriate value)

     --dragons39
     Content-Type: message/sipfrag
     Content-Disposition: aib; handling=optional

--dragons39コンテントタイプ: sipfrag Contentメッセージ/気質: aib。取り扱い=任意です。

     Date: Thu, 21 Feb 2002 13:02:03 GMT
     Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
     Referred-By: <sip:A.example>;cid="23094202342.1012309123@A.example"

日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒、To:を参照します。 <一口: C.の例; =が参照する方法--が=について言及する、「「>は参照した」という<一口: D.の例の>。 <一口: A.の例の>; Cid=" 23094202342.1012309123@A.example "

Sparks                      Standards Track                    [Page 20]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[20ページ]RFC3892をかきたてます。

     --dragons39
     Content-Type: application/pkcs7-signature; name=smime.p7s
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment; filename=smime.p7s;
        handling=required

     (appropriate signature goes here)

(適切な署名はここに行きます)

     --dragons39--
     --unique-boundary-1--

--dragons39----ユニークな境界-1--

  F3 NOTIFY sip:A.example SIP/2.0
     Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
     To: <sip:A.example>;tag=23490234
     From: <sip:B.example>;tag=5923020
     Call-ID: 2304098023@A.example
     CSeq: 29420342 NOTIFY
     Event: refer;id=2342093
     Subscription-State: terminated
     Max-Forwards: 70
     Contact: <sip:B.example>
     Content-Type: message/sipfrag
     Content-Length: (appropriate value)

F3は一口に通知します: 以下を通ってA.例一口/2.0 一口/2.0/UDP A.の例; ブランチ=z9hG4bK3802394232To: <一口: A.の例の>; =23490234From:にタグ付けをしてください。 <一口: B.の例の>; =5923020呼び出しIDにタグ付けをしてください: 2304098023@A.example CSeq: 29420342 出来事に通知してください: 参照してください; イドは2342093Subscription-状態と等しいです: 終えられたマックス-フォワード: 70 接触: <一口: B.例の>コンテントタイプ: sipfrag Contentメッセージ/長さ: (適切な値)

     SIP/2.0 202 Accepted

一口/2.0 202は受け入れました。

  F4 INVITE sip:D.example SIP/2.0
     Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234
     To: <sip:D.example>
     From: <sip:C.example>;tag=023942334
     Call-ID: 23489020352@C.example
     CSeq: 1230934 INVITE
     Max-Forwards: 70
     Contact: <sip:C.example>
     Referred-By: <sip:A.example>;
         cid="23094202342.10123091233@A.example"
     Content-Type: multipart/mixed; boundary=unique-boundary-1
     Content-Length: (appropriate value)

F4は一口を招待します: 以下を通ってD.例一口/2.0 一口/2.0/UDP C.の例; ブランチ=z9hG4bK29348234To: <一口: D.例の>From: <一口: C.の例の>; =023942334呼び出しIDにタグ付けをしてください: 23489020352@C.example CSeq: 1230934 前方へマックスを招待してください: 70 接触: <は参照されていた状態で: C.の例の>をちびちび飲みます: <一口: A.の例の>。 Cidは" 23094202342.10123091233@A.example "コンテントタイプと等しいです: 複合か混ぜられる。境界はユニークな境界-1のContent-長さと等しいです: (適切な値)

     --unique-boundary-1
     Content-Type: application/sdp
     Content-Length: (appropriate value)

--ユニークな境界1コンテントタイプ: sdp Contentアプリケーション/長さ: (適切な値)

Sparks                      Standards Track                    [Page 21]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[21ページ]RFC3892をかきたてます。

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

0 0IN IP4 C.のセッションC2890844526 2890844526IN IP4 C.のv=0o=例s=SDP c=例t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000

     --unique-boundary-1
     Content-Type: multipart/signed;
       protocol="application/pkcs7-signature";
       micalg=sha1; boundary=dragons39
     Content-ID: <23094202342.10123091233@A.example>
     Content-Length: (appropriate value)

     --dragons39
     Content-Type: message/sipfrag
     Content-Disposition: aib; handling=optional

--dragons39コンテントタイプ: sipfrag Contentメッセージ/気質: aib。取り扱い=任意です。

     Date: Thu, 21 Feb 2002 13:02:03 GMT
     Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
     Referred-By: <sip:A.example>;
         cid="23094202342.1012309123@A.example"

日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒、To:を参照します。 <一口: C.の例; =が参照する方法--が=について言及する、「「>は参照した」という<一口: D.の例の>。 <一口: A.の例の>。 Cidは" 23094202342.1012309123@A.example "と等しいです。

     --dragons39
     Content-Type: application/pkcs7-signature; name=smime.p7s
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment; filename=smime.p7s;
        handling=required

     (appropriate signature goes here)

(適切な署名はここに行きます)

     --dragons39--
     --unique-boundary-1--

--dragons39----ユニークな境界-1--

Sparks                      Standards Track                    [Page 22]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[22ページ]RFC3892をかきたてます。

8.  IANA Considerations

8. IANA問題

   This document defines a new SIP header field name with a compact form
   (Referred-By and b respectively).  It also defines a new SIP client
   error response code (429).

このドキュメントがコンパクト形で新しいSIPヘッダーフィールド名を定義する、(参照されている、b、それぞれ) また、それは新しいSIPクライアント誤り応答コード(429)を定義します。

   The following changes are reflected at:

以下の変化は以下で反映されます。

      http:///www.iana.org/assignments/sip-parameters

http:///www.iana.org/assignments/sip-parameters

   The following row has been added to the header field section
   (replacing any existing row for Referred-By).

ヘッダーフィールド部分(近くReferredのためにどんな既存の列も取り替える)に以下の列を追加してあります。

      Header Name             Compact Form               Reference
      Referred-By                  b                     [RFC3892]

ヘッダー近くName Compact Form Reference Referred b[RFC3892]

   The following row has been added to the response code section under
   the Request Failure 4xx heading.

Request Failure 4xx見出しの下の応答コード部に以下の列を追加してあります。

      429 Provide Referrer Identity                     [RFC3892]

429はリファラーのアイデンティティを提供します。[RFC3892]

9.  Contributors

9. 貢献者

   Rohan Mahy distilled RFC2822's msg-id into this document's definition
   of sip-clean-msg-id.

Rohanマーイはこのドキュメントの一口の清潔なmsgイドの定義にRFC2822のmsg-イドを蒸留しました。

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
        Method", RFC 3515, April 2003.

[2] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。

   [3]  Peterson, J., "Session Initiation Protocol (SIP) Authenticated
        Identity Body (AIB) Format", RFC 3893, September 2004.

[3] ピーターソン、J.、「セッション開始プロトコル(一口)はアイデンティティ本体(AIB)形式を認証した」RFC3893、2004年9月。

   [4]  Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
        November 2002.

R.、「インターネットメディアTypeメッセージ/sipfrag」、RFC3420 2002年11月の[4]スパーク。

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

[5] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。「セッション開始プロトコル」、RFC3261、2002年6月。

Sparks                      Standards Track                    [Page 23]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[23ページ]RFC3892をかきたてます。

   [6]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

10.2.  Informative References

10.2. 有益な参照

   [7]  Peterson, J., "Enhancements for Authenticated Identity
        Management in the Session  Initiation Protocol (SIP)", Work in
        Progress, March 2003.

[7] ピーターソン、J.、「セッション開始プロトコル(一口)における認証されたアイデンティティ管理のための増進」が進歩、2003年3月に働いています。

   [8]  Sparks, R. and A. Johnston, "Session Initiation Protocol Call
        Control - Transfer", Work in Progress, February 2003.

[8] 「セッション開始プロトコル呼び出しコントロール--移す」というスパークス、R.、およびA.ジョンストンは進歩、2003年2月に働いています。

   [9]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[9] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

11.  Author's Address

11. 作者のアドレス

   Robert J. Sparks
   Xten
   5100 Tennyson Parkway
   Suite 1000
   Plano, TX  75024

ロバートJ.はXten5100テニソン・公園道路スイート1000プラノ、テキサス 75024をかきたてます。

   EMail: RjS@xten.com

メール: RjS@xten.com

Sparks                      Standards Track                    [Page 24]

RFC 3892             The SIP Referred-By Mechanism        September 2004

参照された一口メカニズム2004年9月に標準化過程[24ページ]RFC3892をかきたてます。

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

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

Sparks                      Standards Track                    [Page 25]

標準化過程をかきたてます。[25ページ]

一覧

RFC 1～100	RFC 1401～1500	RFC 2801～2900	RFC 4201～4300
RFC 101～200	RFC 1501～1600	RFC 2901～3000	RFC 4301～4400
RFC 201～300	RFC 1601～1700	RFC 3001～3100	RFC 4401～4500
RFC 301～400	RFC 1701～1800	RFC 3101～3200	RFC 4501～4600
RFC 401～500	RFC 1801～1900	RFC 3201～3300	RFC 4601～4700
RFC 501～600	RFC 1901～2000	RFC 3301～3400	RFC 4701～4800
RFC 601～700	RFC 2001～2100	RFC 3401～3500	RFC 4801～4900
RFC 701～800	RFC 2101～2200	RFC 3501～3600	RFC 4901～5000
RFC 801～900	RFC 2201～2300	RFC 3601～3700	RFC 5001～5100
RFC 901～1000	RFC 2301～2400	RFC 3701～3800	RFC 5101～5200
RFC 1001～1100	RFC 2401～2500	RFC 3801～3900	RFC 5201～5300
RFC 1101～1200	RFC 2501～2600	RFC 3901～4000	RFC 5301～5400
RFC 1201～1300	RFC 2601～2700	RFC 4001～4100	RFC 5401～5500
RFC 1301～1400	RFC 2701～2800	RFC 4101～4200

RFC3892 日本語訳

一覧

リンク

メニュー

コメント

お問い合わせ

プライバシーポリシー