RFC3261 日本語訳

3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne,G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E.Schooler. June 2002. (Format: TXT=647976 bytes) (Obsoletes RFC2543) (Updated by RFC3265, RFC3853, RFC4320, RFC4916, RFC5393) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                       J. Rosenberg
Request for Comments: 3261                                   dynamicsoft
Obsoletes: 2543                                           H. Schulzrinne
Category: Standards Track                                    Columbia U.
                                                            G. Camarillo
                                                                Ericsson
                                                             A. Johnston
                                                                WorldCom
                                                             J. Peterson
                                                                 Neustar
                                                               R. Sparks
                                                             dynamicsoft
                                                              M. Handley
                                                                    ICIR
                                                             E. Schooler
                                                                    AT&T
                                                               June 2002

コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3261dynamicsoft Obsoletes: 2543時間Schulzrinneカテゴリ: 規格TrackコロンビアU.G.キャマリロエリクソンA.ジョンストンワールドコムJ.ピーターソンNeustar R.スパークスdynamicsoft M.ハンドレーICIR E.Schooler AT&T2002年6月

                    SIP: Session Initiation Protocol

一口: セッション開始プロトコル

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 (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document describes Session Initiation Protocol (SIP), an
   application-layer control (signaling) protocol for creating,
   modifying, and terminating sessions with one or more participants.
   These sessions include Internet telephone calls, multimedia
   distribution, and multimedia conferences.

このドキュメントは1人以上の関係者との作成、変更、および終わりセッションのためにSession Initiationプロトコル(SIP)、応用層規制(シグナリング)プロトコルについて説明します。 これらのセッションはインターネット通話、マルチメディア分配、およびマルチメディア会議を含んでいます。

   SIP invitations used to create sessions carry session descriptions
   that allow participants to agree on a set of compatible media types.
   SIP makes use of elements called proxy servers to help route requests
   to the user's current location, authenticate and authorize users for
   services, implement provider call-routing policies, and provide
   features to users.  SIP also provides a registration function that
   allows users to upload their current locations for use by proxy
   servers.  SIP runs on top of several different transport protocols.

セッションを作成するのに使用されるSIP招待状は関係者が1セットのコンパチブルメディアタイプに同意できるセッション記述を運びます。 SIPはユーザの現在の位置にルート要求を助けて、サービスのためにユーザを認証して、権限を与えて、プロバイダー呼び出しルーティング政策を実施して、特徴をユーザに提供するためにプロキシサーバと呼ばれる要素を利用します。 また、SIPはユーザが使用のために代理人を通して彼らの現在の位置をアップロードできる登録機能にサーバを提供します。 SIPはいくつかの異なったトランスポート・プロトコルの上を走ります。

Rosenberg, et. al.          Standards Track                     [Page 1]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[1ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

Table of Contents

目次

   1          Introduction ........................................    8
   2          Overview of SIP Functionality .......................    9
   3          Terminology .........................................   10
   4          Overview of Operation ...............................   10
   5          Structure of the Protocol ...........................   18
   6          Definitions .........................................   20
   7          SIP Messages ........................................   26
   7.1        Requests ............................................   27
   7.2        Responses ...........................................   28
   7.3        Header Fields .......................................   29
   7.3.1      Header Field Format .................................   30
   7.3.2      Header Field Classification .........................   32
   7.3.3      Compact Form ........................................   32
   7.4        Bodies ..............................................   33
   7.4.1      Message Body Type ...................................   33
   7.4.2      Message Body Length .................................   33
   7.5        Framing SIP Messages ................................   34
   8          General User Agent Behavior .........................   34
   8.1        UAC Behavior ........................................   35
   8.1.1      Generating the Request ..............................   35
   8.1.1.1    Request-URI .........................................   35
   8.1.1.2    To ..................................................   36
   8.1.1.3    From ................................................   37
   8.1.1.4    Call-ID .............................................   37
   8.1.1.5    CSeq ................................................   38
   8.1.1.6    Max-Forwards ........................................   38
   8.1.1.7    Via .................................................   39
   8.1.1.8    Contact .............................................   40
   8.1.1.9    Supported and Require ...............................   40
   8.1.1.10   Additional Message Components .......................   41
   8.1.2      Sending the Request .................................   41
   8.1.3      Processing Responses ................................   42
   8.1.3.1    Transaction Layer Errors ............................   42
   8.1.3.2    Unrecognized Responses ..............................   42
   8.1.3.3    Vias ................................................   43
   8.1.3.4    Processing 3xx Responses ............................   43
   8.1.3.5    Processing 4xx Responses ............................   45
   8.2        UAS Behavior ........................................   46
   8.2.1      Method Inspection ...................................   46
   8.2.2      Header Inspection ...................................   46
   8.2.2.1    To and Request-URI ..................................   46
   8.2.2.2    Merged Requests .....................................   47
   8.2.2.3    Require .............................................   47
   8.2.3      Content Processing ..................................   48
   8.2.4      Applying Extensions .................................   49
   8.2.5      Processing the Request ..............................   49

1つの序論… 一口の機能性の8 2概観… 9 3用語… 10 操作の4概観… 10 5 プロトコルの構造… 18 6つの定義… 20 7 メッセージをちびちび飲んでください… 26 7.1 要求します。 27 7.2の応答… 28 7.3 ヘッダー分野… 29 7.3 .1 ヘッダーフィールド形式… 30 7.3 .2 ヘッダーフィールド分類… 32 7.3 .3コンパクト形… 32 7.4のボディー… 33 7.4 .1 メッセージボディータイプ… 33 7.4 .2 メッセージボディーの長さ… 33 7.5 縁どり一口メッセージ… 34 8 一般ユーザエージェントの振舞い… 34 8.1 UACの振舞い… 35 8.1 .1 要求を発生させます… 35 8.1 .1 .1要求URI… 35 8.1 .1、.2、… 36 8.1 .1、.3、… 37 8.1 .1 .4呼び出しID… 37 8.1 .1 .5CSeq… 38 8.1 .1 .6 マックス-フォワード… を通して38 8.1 .1、.7、… 39 8.1 .1 .8 連絡します。 40 8.1 .1 .9 支持して、必要です。 40 8.1 .1 .10 追加メッセージコンポーネント… 41 8.1 .2 要求を送ります… 41 8.1 .3 処理応答… 42 8.1 .3 .1 取引層の誤り… 42 8.1 .3 .2 認識されていない応答… 42 8.1 .3 .3Vias… 43 8.1 .3 .4 処理3xx応答… 43 8.1 .3 .5 処理4xx応答… 45 8.2 UASの振舞い… 46 8.2 .1 方法点検… 46 8.2 .2 ヘッダー点検… そして、46 8.2 .2、.1、要求URI… 46 8.2 .2 .2は要求を合併しました… 47 8.2 .2 .3 必要です。 47 8.2 .3 満足している処理… 48 8.2 .4 拡大を適用します… 49 8.2 .5 要求を処理します… 49

Rosenberg, et. al.          Standards Track                     [Page 2]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[2ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   8.2.6      Generating the Response .............................   49
   8.2.6.1    Sending a Provisional Response ......................   49
   8.2.6.2    Headers and Tags ....................................   50
   8.2.7      Stateless UAS Behavior ..............................   50
   8.3        Redirect Servers ....................................   51
   9          Canceling a Request .................................   53
   9.1        Client Behavior .....................................   53
   9.2        Server Behavior .....................................   55
   10         Registrations .......................................   56
   10.1       Overview ............................................   56
   10.2       Constructing the REGISTER Request ...................   57
   10.2.1     Adding Bindings .....................................   59
   10.2.1.1   Setting the Expiration Interval of Contact Addresses    60
   10.2.1.2   Preferences among Contact Addresses .................   61
   10.2.2     Removing Bindings ...................................   61
   10.2.3     Fetching Bindings ...................................   61
   10.2.4     Refreshing Bindings .................................   61
   10.2.5     Setting the Internal Clock ..........................   62
   10.2.6     Discovering a Registrar .............................   62
   10.2.7     Transmitting a Request ..............................   62
   10.2.8     Error Responses .....................................   63
   10.3       Processing REGISTER Requests ........................   63
   11         Querying for Capabilities ...........................   66
   11.1       Construction of OPTIONS Request .....................   67
   11.2       Processing of OPTIONS Request .......................   68
   12         Dialogs .............................................   69
   12.1       Creation of a Dialog ................................   70
   12.1.1     UAS behavior ........................................   70
   12.1.2     UAC Behavior ........................................   71
   12.2       Requests within a Dialog ............................   72
   12.2.1     UAC Behavior ........................................   73
   12.2.1.1   Generating the Request ..............................   73
   12.2.1.2   Processing the Responses ............................   75
   12.2.2     UAS Behavior ........................................   76
   12.3       Termination of a Dialog .............................   77
   13         Initiating a Session ................................   77
   13.1       Overview ............................................   77
   13.2       UAC Processing ......................................   78
   13.2.1     Creating the Initial INVITE .........................   78
   13.2.2     Processing INVITE Responses .........................   81
   13.2.2.1   1xx Responses .......................................   81
   13.2.2.2   3xx Responses .......................................   81
   13.2.2.3   4xx, 5xx and 6xx Responses ..........................   81
   13.2.2.4   2xx Responses .......................................   82
   13.3       UAS Processing ......................................   83
   13.3.1     Processing of the INVITE ............................   83
   13.3.1.1   Progress ............................................   84
   13.3.1.2   The INVITE is Redirected ............................   84

8.2.6 応答を発生させます… 49 8.2 .6 .1 暫定的な応答を送ります… 49 8.2 .6 .2個のヘッダーとタグ… 50 8.2 .7 国がないUASの振舞い… 50 8.3 サーバを向け直してください… 51 9 要求を中止します… 53 9.1 クライアントの振舞い… 53 9.2 サーバの振舞い… 55 10の登録証明書… 56 10.1概観… 56 10.2 レジスタ要求を構成します… 57 10.2.1 結合を加えます… 59 10.2.1.1 接触の満了間隔を設定すると、連絡先の中の60 10.2の.1.2好みが記述されます… 61 10.2.2 結合を取り除きます… 61 10.2.3 魅惑的な結合… 61 10.2.4 壮快な結合… 61 10.2.5 内部クロックを設定します… 62 10.2.6 記録係を発見します… 62 10.2.7 要求を伝えます… 62 10.2.8 誤り応答… 63 10.3 処理レジスタ要求… 能力のために質問される63 11… 66 11.1 オプション要求の工事… 67 11.2 オプション要求の処理… 68 12の対話… 対話の69 12.1創造… 70 12.1.1 UASの振舞い… 70 12.1.2 UACの振舞い… 71 12.2 対話の中で要求します。 72 12.2.1 UACの振舞い… 73 12.2.1.1 要求を発生させます… 73 12.2.1.2 応答を処理します… 75 12.2.2 UASの振舞い… 76 12.3 対話の終了… セッションを開始する77 13… 77 13.1概観… 77 13.2 UAC処理… 78 13.2.1 初期が招待する作成… 78 13.2.2 処理して、応答を招待してください… 81 13.2.2.1 1 xx応答… 81 13.2.2.2 3 xx応答… 81 13.2.2.3 4 xx、5xx、および6xx応答… 81 13.2.2.4 2 xx応答… 82 13.3 UAS処理… 83 13.3.1 招待の処理… 83 13.3.1.1 進歩をしてください… 84 13.3.1.2 INVITEはRedirectedです… 84

Rosenberg, et. al.          Standards Track                     [Page 3]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[3ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   13.3.1.3   The INVITE is Rejected ..............................   85
   13.3.1.4   The INVITE is Accepted ..............................   85
   14         Modifying an Existing Session .......................   86
   14.1       UAC Behavior ........................................   86
   14.2       UAS Behavior ........................................   88
   15         Terminating a Session ...............................   89
   15.1       Terminating a Session with a BYE Request ............   90
   15.1.1     UAC Behavior ........................................   90
   15.1.2     UAS Behavior ........................................   91
   16         Proxy Behavior ......................................   91
   16.1       Overview ............................................   91
   16.2       Stateful Proxy ......................................   92
   16.3       Request Validation ..................................   94
   16.4       Route Information Preprocessing .....................   96
   16.5       Determining Request Targets .........................   97
   16.6       Request Forwarding ..................................   99
   16.7       Response Processing .................................  107
   16.8       Processing Timer C ..................................  114
   16.9       Handling Transport Errors ...........................  115
   16.10      CANCEL Processing ...................................  115
   16.11      Stateless Proxy .....................................  116
   16.12      Summary of Proxy Route Processing ...................  118
   16.12.1    Examples ............................................  118
   16.12.1.1  Basic SIP Trapezoid .................................  118
   16.12.1.2  Traversing a Strict-Routing Proxy ...................  120
   16.12.1.3  Rewriting Record-Route Header Field Values ..........  121
   17         Transactions ........................................  122
   17.1       Client Transaction ..................................  124
   17.1.1     INVITE Client Transaction ...........................  125
   17.1.1.1   Overview of INVITE Transaction ......................  125
   17.1.1.2   Formal Description ..................................  125
   17.1.1.3   Construction of the ACK Request .....................  129
   17.1.2     Non-INVITE Client Transaction .......................  130
   17.1.2.1   Overview of the non-INVITE Transaction ..............  130
   17.1.2.2   Formal Description ..................................  131
   17.1.3     Matching Responses to Client Transactions ...........  132
   17.1.4     Handling Transport Errors ...........................  133
   17.2       Server Transaction ..................................  134
   17.2.1     INVITE Server Transaction ...........................  134
   17.2.2     Non-INVITE Server Transaction .......................  137
   17.2.3     Matching Requests to Server Transactions ............  138
   17.2.4     Handling Transport Errors ...........................  141
   18         Transport ...........................................  141
   18.1       Clients .............................................  142
   18.1.1     Sending Requests ....................................  142
   18.1.2     Receiving Responses .................................  144
   18.2       Servers .............................................  145
   18.2.1     Receiving Requests ..................................  145

13.3.1.3 INVITEはRejectedです… 85 13.3.1.4 INVITEはAcceptedです… 既存のセッションを変更する85 14… 86 14.1 UACの振舞い… 86 14.2 UASの振舞い… セッションを終える88 15… 89 15.1 さようなら要求とのセッションを終えます… 90 15.1.1 UACの振舞い… 90 15.1.2 UASの振舞い… 91 16プロキシの振舞い… 91 16.1概観… 91 16.2はプロキシをStatefulします… 92 16.3 合法化を要求してください… 94 16.4 情報前処理を発送してください… 96 16.5 要求目標を決定します… 97 16.6 推進を要求してください… 99 16.7 応答処理… 107 16.8 処理タイマC… 114 16.9 取り扱い輸送誤り… 115 16.10 処理を中止してください… 115 16.11 国がないプロキシ… 116 プロキシルート処理の16.12概要… 118 16.12 .1の例… 118 16.12 .1 .1の基本的な一口台形… 118 16.12 .1 .2 厳しいルート設定プロキシを横断します… 120 16.12 .1 記録的なルートヘッダーを書き直す.3が値をさばきます… 121 17の取引… 122 17.1 クライアント取引… 124 17.1 .1 クライアント取引を招待してください… 125 17.1 .1 招待取引の.1概観… 125 17.1 .1 .2 正式な記述… 125 17.1 .1 .3 ACK要求の工事… 129 17.1 .2 非招待クライアント取引… 130 17.1 .2 非招待取引の.1概観… 130 17.1 .2 .2 正式な記述… 131 17.1 .3 クライアント取引への合っている応答… 132 17.1 .4 取り扱い輸送誤り… 133 17.2 サーバ取引… 134 17.2 .1 サーバ取引を招待してください… 134 17.2 .2 非招待サーバ取引… 137 17.2 .3 サーバ取引に要求に合っています… 138 17.2 .4 取り扱い輸送誤り… 141 18 輸送… 141 18.1人のクライアント… 142 18.1 .1 送付要求… 142 18.1 .2 応答を受けます… 144 18.2のサーバ… 145 18.2 .1 要求を受け取ります… 145

Rosenberg, et. al.          Standards Track                     [Page 4]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[4ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   18.2.2     Sending Responses ...................................  146
   18.3       Framing .............................................  147
   18.4       Error Handling ......................................  147
   19         Common Message Components ...........................  147
   19.1       SIP and SIPS Uniform Resource Indicators ............  148
   19.1.1     SIP and SIPS URI Components .........................  148
   19.1.2     Character Escaping Requirements .....................  152
   19.1.3     Example SIP and SIPS URIs ...........................  153
   19.1.4     URI Comparison ......................................  153
   19.1.5     Forming Requests from a URI .........................  156
   19.1.6     Relating SIP URIs and tel URLs ......................  157
   19.2       Option Tags .........................................  158
   19.3       Tags ................................................  159
   20         Header Fields .......................................  159
   20.1       Accept ..............................................  161
   20.2       Accept-Encoding .....................................  163
   20.3       Accept-Language .....................................  164
   20.4       Alert-Info ..........................................  164
   20.5       Allow ...............................................  165
   20.6       Authentication-Info .................................  165
   20.7       Authorization .......................................  165
   20.8       Call-ID .............................................  166
   20.9       Call-Info ...........................................  166
   20.10      Contact .............................................  167
   20.11      Content-Disposition .................................  168
   20.12      Content-Encoding ....................................  169
   20.13      Content-Language ....................................  169
   20.14      Content-Length ......................................  169
   20.15      Content-Type ........................................  170
   20.16      CSeq ................................................  170
   20.17      Date ................................................  170
   20.18      Error-Info ..........................................  171
   20.19      Expires .............................................  171
   20.20      From ................................................  172
   20.21      In-Reply-To .........................................  172
   20.22      Max-Forwards ........................................  173
   20.23      Min-Expires .........................................  173
   20.24      MIME-Version ........................................  173
   20.25      Organization ........................................  174
   20.26      Priority ............................................  174
   20.27      Proxy-Authenticate ..................................  174
   20.28      Proxy-Authorization .................................  175
   20.29      Proxy-Require .......................................  175
   20.30      Record-Route ........................................  175
   20.31      Reply-To ............................................  176
   20.32      Require .............................................  176
   20.33      Retry-After .........................................  176
   20.34      Route ...............................................  177

18.2.2 送付応答… 146 18.3 縁どっています。 147 18.4エラー処理… 147 19 一般的なメッセージコンポーネント… 147 19.1 一定のリソースインディケータをちびちび飲んで、ちびちび飲みます… 148 19.1 .1 URIコンポーネントをちびちび飲んで、ちびちび飲みます… 148 19.1 要件から逃げる.2キャラクター… 152 19.1 .3 例の一口と一口URI… 153 19.1 .4 URI比較… 153 19.1 .5 URIから要求を形成します… 156 19.1 .6 SIP URIとtel URLを関係づけます… 157 19.2 オプションタグ… 158 19.3 タグ付けをします。 159 20 ヘッダー分野… 159 20.1 受け入れてください… 161 20.2 コード化を受け入れます… 163 20.3 言語を受け入れます… 164 20.4 注意深いインフォメーション… 164 20.5 許容します。 165 20.6認証インフォメーション… 165 20.7認可… 165 20.8呼び出しID… 166 20.9呼び出しインフォメーション… 166 20.10 連絡します。 167 20.11 満足している気質… 168 20.12 内容をコード化しています… 169 20.13 満足している言語… 169 20.14 満足している長さ… 169 20.15コンテントタイプ… 170 20.16CSeq… 170 20.17 デートしてください… 170 20.18誤りインフォメーション… 171 20.19 期限が切れます… 171、20.20、… 172 20.21 …に対して… 172 20.22 マックス-フォワード… 173 20.23 分期限が切れます… 173 20.24MIMEバージョン… 173 20.25組織… 174 20.26優先権… 174 20.27 …をプロキシで認証してください… 174 20.28プロキシ認可… 175 20.29 …をプロキシで必要としてください… 175 20.30 記録的なルート… 175 20.31 答えます。 176 20.32 必要です。 176 20.33 -後に再試行してください… 176 20.34 発送します。 177

Rosenberg, et. al.          Standards Track                     [Page 5]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[5ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   20.35      Server ..............................................  177
   20.36      Subject .............................................  177
   20.37      Supported ...........................................  178
   20.38      Timestamp ...........................................  178
   20.39      To ..................................................  178
   20.40      Unsupported .........................................  179
   20.41      User-Agent ..........................................  179
   20.42      Via .................................................  179
   20.43      Warning .............................................  180
   20.44      WWW-Authenticate ....................................  182
   21         Response Codes ......................................  182
   21.1       Provisional 1xx .....................................  182
   21.1.1     100 Trying ..........................................  183
   21.1.2     180 Ringing .........................................  183
   21.1.3     181 Call Is Being Forwarded .........................  183
   21.1.4     182 Queued ..........................................  183
   21.1.5     183 Session Progress ................................  183
   21.2       Successful 2xx ......................................  183
   21.2.1     200 OK ..............................................  183
   21.3       Redirection 3xx .....................................  184
   21.3.1     300 Multiple Choices ................................  184
   21.3.2     301 Moved Permanently ...............................  184
   21.3.3     302 Moved Temporarily ...............................  184
   21.3.4     305 Use Proxy .......................................  185
   21.3.5     380 Alternative Service .............................  185
   21.4       Request Failure 4xx .................................  185
   21.4.1     400 Bad Request .....................................  185
   21.4.2     401 Unauthorized ....................................  185
   21.4.3     402 Payment Required ................................  186
   21.4.4     403 Forbidden .......................................  186
   21.4.5     404 Not Found .......................................  186
   21.4.6     405 Method Not Allowed ..............................  186
   21.4.7     406 Not Acceptable ..................................  186
   21.4.8     407 Proxy Authentication Required ...................  186
   21.4.9     408 Request Timeout .................................  186
   21.4.10    410 Gone ............................................  187
   21.4.11    413 Request Entity Too Large ........................  187
   21.4.12    414 Request-URI Too Long ............................  187
   21.4.13    415 Unsupported Media Type ..........................  187
   21.4.14    416 Unsupported URI Scheme ..........................  187
   21.4.15    420 Bad Extension ...................................  187
   21.4.16    421 Extension Required ..............................  188
   21.4.17    423 Interval Too Brief ..............................  188
   21.4.18    480 Temporarily Unavailable .........................  188
   21.4.19    481 Call/Transaction Does Not Exist .................  188
   21.4.20    482 Loop Detected ...................................  188
   21.4.21    483 Too Many Hops ...................................  189
   21.4.22    484 Address Incomplete ..............................  189

20.35サーバ… 177 20.36 かけます。 177 20.37 支持されます… 178 20.38タイムスタンプ… 178、20.39、… 178 20.40 サポートされない… 179 20.41ユーザエージェント… を通して179、20.42、… 179 20.43 警告… 180 20.44 …をWWW認証してください… 182 21 応答コード… 182 21.1 暫定的な1xx… 182 21.1.1 100 試みること… 183 21.1.2 180 鳴ること… 183 21.1.3 181呼び出しを進めています… 183 21.1.4 182は列を作りました… 183 21.1.5 183セッション進歩… 183 21.2 うまくいっている2xx… 183 21.2.1 200 OK… 183 21.3リダイレクション3xx… 184 21.3.1 300 選択式… 184 21.3.2 301は永久に、動きました… 184 21.3.3 302は一時動きました… 184 21.3.4 305 プロキシを使用してください… 185 21.3.5 380代替手段サービス… 185 21.4 失敗4xxを要求してください… 185の21.4.1 400の悪い要求… 185 21.4.2 401 権限のない… 185 21.4.3 402支払いが必要です… 186 21.4.4 403 禁じられます… 186 21.4.5 404 見つけられません… 186 21.4.6 405 許容されなかった方法… 186 21.4.7 406 許容できない… 186 21.4.8 407プロキシ認証が必要です… 186 21.4.9 408 タイムアウトを要求してください… 186 21.4.10 410 行きます… 187 21.4.11 413 大き過ぎる状態で実体を要求してください… 187 21.4.12 414要求URIも長さ………………………。 187 21.4.13 415 サポートされないメディアタイプ… 187の21.4.14 416のサポートされないURI計画… 187 21.4.15 420 悪い拡大… 187 21.4.16 421拡大が必要です… 21.4.17 423間隔も事情を知らせる188… 188 21.4.18 480 一時入手できません… 188 21.4.19 481呼び出し/取引は存在していません… 188 21.4.20 482 検出されていた状態で、輪にしてください… 188 21.4.21 483 多く過ぎるのが跳びます… 189 21.4.22 484アドレス不完全… 189

Rosenberg, et. al.          Standards Track                     [Page 6]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[6ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   21.4.23    485 Ambiguous .......................................  189
   21.4.24    486 Busy Here .......................................  189
   21.4.25    487 Request Terminated ..............................  190
   21.4.26    488 Not Acceptable Here .............................  190
   21.4.27    491 Request Pending .................................  190
   21.4.28    493 Undecipherable ..................................  190
   21.5       Server Failure 5xx ..................................  190
   21.5.1     500 Server Internal Error ...........................  190
   21.5.2     501 Not Implemented .................................  191
   21.5.3     502 Bad Gateway .....................................  191
   21.5.4     503 Service Unavailable .............................  191
   21.5.5     504 Server Time-out .................................  191
   21.5.6     505 Version Not Supported ...........................  192
   21.5.7     513 Message Too Large ...............................  192
   21.6       Global Failures 6xx .................................  192
   21.6.1     600 Busy Everywhere .................................  192
   21.6.2     603 Decline .........................................  192
   21.6.3     604 Does Not Exist Anywhere .........................  192
   21.6.4     606 Not Acceptable ..................................  192
   22         Usage of HTTP Authentication ........................  193
   22.1       Framework ...........................................  193
   22.2       User-to-User Authentication .........................  195
   22.3       Proxy-to-User Authentication ........................  197
   22.4       The Digest Authentication Scheme ....................  199
   23         S/MIME ..............................................  201
   23.1       S/MIME Certificates .................................  201
   23.2       S/MIME Key Exchange .................................  202
   23.3       Securing MIME bodies ................................  205
   23.4       SIP Header Privacy and Integrity using S/MIME:
              Tunneling SIP .......................................  207
   23.4.1     Integrity and Confidentiality Properties of SIP
              Headers .............................................  207
   23.4.1.1   Integrity ...........................................  207
   23.4.1.2   Confidentiality .....................................  208
   23.4.2     Tunneling Integrity and Authentication ..............  209
   23.4.3     Tunneling Encryption ................................  211
   24         Examples ............................................  213
   24.1       Registration ........................................  213
   24.2       Session Setup .......................................  214
   25         Augmented BNF for the SIP Protocol ..................  219
   25.1       Basic Rules .........................................  219
   26         Security Considerations: Threat Model and Security
              Usage Recommendations ...............................  232
   26.1       Attacks and Threat Models ...........................  233
   26.1.1     Registration Hijacking ..............................  233
   26.1.2     Impersonating a Server ..............................  234
   26.1.3     Tampering with Message Bodies .......................  235
   26.1.4     Tearing Down Sessions ...............................  235

21.4.23 485 あいまい… 189 21.4.24 486 ここで忙しい… 189 21.4.25 487要求は終わりました… 190 21.4.26 488 ここで許容できない… 未定の190 21.4.27 491要求… 190 21.4.28 493Undecipherable… 190 21.5 サーバ失敗5xx… 190 21.5.1 500サーバ内部エラー… 190 21.5.2 501 実行されません… 191 21.5.3 502 悪いゲートウェイ… 入手できない191 21.5.4 503サービス… 191 21.5.5 504サーバタイムアウト… 191 21.5.6 505 支持されなかったバージョン… 192 21.5.7 513 また、多、を通信させてください… 192 21.6 グローバルな失敗6xx… 192 21.6.1 600 いたる所で忙しい… 192 21.6.2 603 減退してください… 192 21.6.3 604 何処にも、存在していません… 192 21.6.4 606 許容できない… 192 22 HTTP認証の用法… 193 22.1枠組み… 193 ユーザー認証への22.2ユーザ… 195 ユーザー認証への22.3プロキシ… 197 22.4 ダイジェスト認証計画… 199 23秒間/MIME… 201 23.1秒間/MIMEの証明書… 201 23.2秒間/MIMEの間の主要な交換… 202 23.3 MIME本体を保証します… 205 23.4 S/MIMEを使用して、ヘッダープライバシーと保全をちびちび飲んでください: トンネリング一口… 207 23.4 .1 一口ヘッダーの保全と秘密性の特性… 207 23.4 .1 .1保全… 207 23.4 .1 .2秘密性… 208 23.4 .2 保全と認証にトンネルを堀ります… 209 23.4 .3トンネリング暗号化… 211 24の例… 213 24.1登録… 213 24.2 セッションセットアップ… 214 25は一口プロトコルのためにBNFを増大させました… 219 25.1 基本的な規則… 219 26 セキュリティ問題: 脅威モデルとセキュリティ用法推薦… 232 26.1の攻撃と脅威モデル… 233 26.1 .1 登録ハイジャック… 233 26.1 .2 サーバをまねます… 234 26.1 .3 メッセージ本体をいじります… 235 26.1 .4 セッションを取りこわします… 235

Rosenberg, et. al.          Standards Track                     [Page 7]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[7ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   26.1.5     Denial of Service and Amplification .................  236
   26.2       Security Mechanisms .................................  237
   26.2.1     Transport and Network Layer Security ................  238
   26.2.2     SIPS URI Scheme .....................................  239
   26.2.3     HTTP Authentication .................................  240
   26.2.4     S/MIME ..............................................  240
   26.3       Implementing Security Mechanisms ....................  241
   26.3.1     Requirements for Implementers of SIP ................  241
   26.3.2     Security Solutions ..................................  242
   26.3.2.1   Registration ........................................  242
   26.3.2.2   Interdomain Requests ................................  243
   26.3.2.3   Peer-to-Peer Requests ...............................  245
   26.3.2.4   DoS Protection ......................................  246
   26.4       Limitations .........................................  247
   26.4.1     HTTP Digest .........................................  247
   26.4.2     S/MIME ..............................................  248
   26.4.3     TLS .................................................  249
   26.4.4     SIPS URIs ...........................................  249
   26.5       Privacy .............................................  251
   27         IANA Considerations .................................  252
   27.1       Option Tags .........................................  252
   27.2       Warn-Codes ..........................................  252
   27.3       Header Field Names ..................................  253
   27.4       Method and Response Codes ...........................  253
   27.5       The "message/sip" MIME type.  .......................  254
   27.6       New Content-Disposition Parameter Registrations .....  255
   28         Changes From RFC 2543 ...............................  255
   28.1       Major Functional Changes ............................  255
   28.2       Minor Functional Changes ............................  260
   29         Normative References ................................  261
   30         Informative References ..............................  262
   A          Table of Timer Values ...............................  265
   Acknowledgments ................................................  266
   Authors' Addresses .............................................  267
   Full Copyright Statement .......................................  269

26.1.5 Denial of Service and Amplification ................. 236 26.2 Security Mechanisms ................................. 237 26.2.1 Transport and Network Layer Security ................ 238 26.2.2 SIPS URI Scheme ..................................... 239 26.2.3 HTTP Authentication ................................. 240 26.2.4 S/MIME .............................................. 240 26.3 Implementing Security Mechanisms .................... 241 26.3.1 Requirements for Implementers of SIP ................ 241 26.3.2 Security Solutions .................................. 242 26.3.2.1 Registration ........................................ 242 26.3.2.2 Interdomain Requests ................................ 243 26.3.2.3 Peer-to-Peer Requests ............................... 245 26.3.2.4 DoS Protection ...................................... 246 26.4 Limitations ......................................... 247 26.4.1 HTTP Digest ......................................... 247 26.4.2 S/MIME .............................................. 248 26.4.3 TLS ................................................. 249 26.4.4 SIPS URIs ........................................... 249 26.5 Privacy ............................................. 251 27 IANA Considerations ................................. 252 27.1 Option Tags ......................................... 252 27.2 Warn-Codes .......................................... 252 27.3 Header Field Names .................................. 253 27.4 Method and Response Codes ........................... 253 27.5 The "message/sip" MIME type. ....................... 254 27.6 New Content-Disposition Parameter Registrations ..... 255 28 Changes From RFC 2543 ............................... 255 28.1 Major Functional Changes ............................ 255 28.2 Minor Functional Changes ............................ 260 29 Normative References ................................ 261 30 Informative References .............................. 262 A Table of Timer Values ............................... 265 Acknowledgments ................................................ 266 Authors' Addresses ............................................. 267 Full Copyright Statement ....................................... 269

1 Introduction

1 Introduction

   There are many applications of the Internet that require the creation
   and management of a session, where a session is considered an
   exchange of data between an association of participants.  The
   implementation of these applications is complicated by the practices
   of participants: users may move between endpoints, they may be
   addressable by multiple names, and they may communicate in several
   different media - sometimes simultaneously.  Numerous protocols have
   been authored that carry various forms of real-time multimedia
   session data such as voice, video, or text messages.  The Session
   Initiation Protocol (SIP) works in concert with these protocols by

There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by

Rosenberg, et. al.          Standards Track                     [Page 8]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 8] RFC 3261 SIP: Session Initiation Protocol June 2002

   enabling Internet endpoints (called user agents) to discover one
   another and to agree on a characterization of a session they would
   like to share.  For locating prospective session participants, and
   for other functions, SIP enables the creation of an infrastructure of
   network hosts (called proxy servers) to which user agents can send
   registrations, invitations to sessions, and other requests.  SIP is
   an agile, general-purpose tool for creating, modifying, and
   terminating sessions that works independently of underlying transport
   protocols and without dependency on the type of session that is being
   established.

enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established.

2 Overview of SIP Functionality

2 Overview of SIP Functionality

   SIP is an application-layer control protocol that can establish,
   modify, and terminate multimedia sessions (conferences) such as
   Internet telephony calls.  SIP can also invite participants to
   already existing sessions, such as multicast conferences.  Media can
   be added to (and removed from) an existing session.  SIP
   transparently supports name mapping and redirection services, which
   supports personal mobility [27] - users can maintain a single
   externally visible identifier regardless of their network location.

SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility [27] - users can maintain a single externally visible identifier regardless of their network location.

   SIP supports five facets of establishing and terminating multimedia
   communications:

SIP supports five facets of establishing and terminating multimedia communications:

      User location: determination of the end system to be used for
           communication;

User location: determination of the end system to be used for communication;

      User availability: determination of the willingness of the called
           party to engage in communications;

User availability: determination of the willingness of the called party to engage in communications;

      User capabilities: determination of the media and media parameters
           to be used;

User capabilities: determination of the media and media parameters to be used;

      Session setup: "ringing", establishment of session parameters at
           both called and calling party;

Session setup: "ringing", establishment of session parameters at both called and calling party;

      Session management: including transfer and termination of
           sessions, modifying session parameters, and invoking
           services.

Session management: including transfer and termination of sessions, modifying session parameters, and invoking services.

   SIP is not a vertically integrated communications system.  SIP is
   rather a component that can be used with other IETF protocols to
   build a complete multimedia architecture.  Typically, these
   architectures will include protocols such as the Real-time Transport
   Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
   providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
   2326 [29]) for controlling delivery of streaming media, the Media

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media

Rosenberg, et. al.          Standards Track                     [Page 9]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 9] RFC 3261 SIP: Session Initiation Protocol June 2002

   Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
   gateways to the Public Switched Telephone Network (PSTN), and the
   Session Description Protocol (SDP) (RFC 2327 [1]) for describing
   multimedia sessions.  Therefore, SIP should be used in conjunction
   with other protocols in order to provide complete services to the
   users.  However, the basic functionality and operation of SIP does
   not depend on any of these protocols.

Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols.

   SIP does not provide services.  Rather, SIP provides primitives that
   can be used to implement different services.  For example, SIP can
   locate a user and deliver an opaque object to his current location.
   If this primitive is used to deliver a session description written in
   SDP, for instance, the endpoints can agree on the parameters of a
   session.  If the same primitive is used to deliver a photo of the
   caller as well as the session description, a "caller ID" service can
   be easily implemented.  As this example shows, a single primitive is
   typically used to provide several different services.

SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services.

   SIP does not offer conference control services such as floor control
   or voting and does not prescribe how a conference is to be managed.
   SIP can be used to initiate a session that uses some other conference
   control protocol.  Since SIP messages and the sessions they establish
   can pass through entirely different networks, SIP cannot, and does
   not, provide any kind of network resource reservation capabilities.

SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities.

   The nature of the services provided make security particularly
   important.  To that end, SIP provides a suite of security services,
   which include denial-of-service prevention, authentication (both user
   to user and proxy to user), integrity protection, and encryption and
   privacy services.

The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services.

   SIP works with both IPv4 and IPv6.

SIP works with both IPv4 and IPv6.

3 Terminology

3 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [2] and indicate requirement levels for
   compliant SIP implementations.

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.

4 Overview of Operation

4 Overview of Operation

   This section introduces the basic operations of SIP using simple
   examples.  This section is tutorial in nature and does not contain
   any normative statements.

This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements.

Rosenberg, et. al.          Standards Track                    [Page 10]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 10] RFC 3261 SIP: Session Initiation Protocol June 2002

   The first example shows the basic functions of SIP: location of an
   end point, signal of a desire to communicate, negotiation of session
   parameters to establish the session, and teardown of the session once
   established.

The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established.

   Figure 1 shows a typical example of a SIP message exchange between
   two users, Alice and Bob.  (Each message is labeled with the letter
   "F" and a number for reference by the text.)  In this example, Alice
   uses a SIP application on her PC (referred to as a softphone) to call
   Bob on his SIP phone over the Internet.  Also shown are two SIP proxy
   servers that act on behalf of Alice and Bob to facilitate the session
   establishment.  This typical arrangement is often referred to as the
   "SIP trapezoid" as shown by the geometric shape of the dotted lines
   in Figure 1.

Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each message is labeled with the letter "F" and a number for reference by the text.) In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the "SIP trapezoid" as shown by the geometric shape of the dotted lines in Figure 1.

   Alice "calls" Bob using his SIP identity, a type of Uniform Resource
   Identifier (URI) called a SIP URI. SIP URIs are defined in Section
   19.1.  It has a similar form to an email address, typically
   containing a username and a host name.  In this case, it is
   sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP
   service provider.  Alice has a SIP URI of sip:alice@atlanta.com.
   Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
   or an entry in an address book.  SIP also provides a secure URI,
   called a SIPS URI.  An example would be sips:bob@biloxi.com.  A call
   made to a SIPS URI guarantees that secure, encrypted transport
   (namely TLS) is used to carry all SIP messages from the caller to the
   domain of the callee.  From there, the request is sent securely to
   the callee, but with security mechanisms that depend on the policy of
   the domain of the callee.

Alice "calls" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section 19.1. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:alice@atlanta.com. Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be sips:bob@biloxi.com. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee.

   SIP is based on an HTTP-like request/response transaction model.
   Each transaction consists of a request that invokes a particular
   method, or function, on the server and at least one response.  In
   this example, the transaction begins with Alice's softphone sending
   an INVITE request addressed to Bob's SIP URI.  INVITE is an example
   of a SIP method that specifies the action that the requestor (Alice)
   wants the server (Bob) to take.  The INVITE request contains a number
   of header fields.  Header fields are named attributes that provide
   additional information about a message.  The ones present in an
   INVITE include a unique identifier for the call, the destination
   address, Alice's address, and information about the type of session
   that Alice wishes to establish with Bob.  The INVITE (message F1 in
   Figure 1) might look like this:

SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice's address, and information about the type of session that Alice wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this:

Rosenberg, et. al.          Standards Track                    [Page 11]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 11] RFC 3261 SIP: Session Initiation Protocol June 2002

                     atlanta.com  . . . biloxi.com
                 .      proxy              proxy     .
               .                                       .
       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | |

         Figure 1: SIP session setup example with SIP trapezoid

Figure 1: SIP session setup example with SIP trapezoid

      INVITE sip:bob@biloxi.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
      Max-Forwards: 70
      To: Bob <sip:bob@biloxi.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710@pc33.atlanta.com
      CSeq: 314159 INVITE
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: application/sdp
      Content-Length: 142

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142

      (Alice's SDP not shown)

(Alice's SDP not shown)

   The first line of the text-encoded message contains the method name
   (INVITE).  The lines that follow are a list of header fields.  This
   example contains a minimum required set.  The header fields are
   briefly described below:

The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below:

Rosenberg, et. al.          Standards Track                    [Page 12]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 12] RFC 3261 SIP: Session Initiation Protocol June 2002

   Via contains the address (pc33.atlanta.com) at which Alice is
   expecting to receive responses to this request.  It also contains a
   branch parameter that identifies this transaction.

Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction.

   To contains a display name (Bob) and a SIP or SIPS URI
   (sip:bob@biloxi.com) towards which the request was originally
   directed.  Display names are described in RFC 2822 [3].

To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the request was originally directed. Display names are described in RFC 2822 [3].

   From also contains a display name (Alice) and a SIP or SIPS URI
   (sip:alice@atlanta.com) that indicate the originator of the request.
   This header field also has a tag parameter containing a random string
   (1928301774) that was added to the URI by the softphone.  It is used
   for identification purposes.

From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the softphone. It is used for identification purposes.

   Call-ID contains a globally unique identifier for this call,
   generated by the combination of a random string and the softphone's
   host name or IP address.  The combination of the To tag, From tag,
   and Call-ID completely defines a peer-to-peer SIP relationship
   between Alice and Bob and is referred to as a dialog.

Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog.

   CSeq or Command Sequence contains an integer and a method name.  The
   CSeq number is incremented for each new request within a dialog and
   is a traditional sequence number.

CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.

   Contact contains a SIP or SIPS URI that represents a direct route to
   contact Alice, usually composed of a username at a fully qualified
   domain name (FQDN).  While an FQDN is preferred, many end systems do
   not have registered domain names, so IP addresses are permitted.
   While the Via header field tells other elements where to send the
   response, the Contact header field tells other elements where to send
   future requests.

Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.

   Max-Forwards serves to limit the number of hops a request can make on
   the way to its destination.  It consists of an integer that is
   decremented by one at each hop.

Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.

   Content-Type contains a description of the message body (not shown).

Content-Type contains a description of the message body (not shown).

   Content-Length contains an octet (byte) count of the message body.

Content-Length contains an octet (byte) count of the message body.

   The complete set of SIP header fields is defined in Section 20.

The complete set of SIP header fields is defined in Section 20.

   The details of the session, such as the type of media, codec, or
   sampling rate, are not described using SIP.  Rather, the body of a
   SIP message contains a description of the session, encoded in some
   other protocol format.  One such format is the Session Description
   Protocol (SDP) (RFC 2327 [1]).  This SDP message (not shown in the

The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the

Rosenberg, et. al.          Standards Track                    [Page 13]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 13] RFC 3261 SIP: Session Initiation Protocol June 2002

   example) is carried by the SIP message in a way that is analogous to
   a document attachment being carried by an email message, or a web
   page being carried in an HTTP message.

example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message.

   Since the softphone does not know the location of Bob or the SIP
   server in the biloxi.com domain, the softphone sends the INVITE to
   the SIP server that serves Alice's domain, atlanta.com.  The address
   of the atlanta.com SIP server could have been configured in Alice's
   softphone, or it could have been discovered by DHCP, for example.

Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example.

   The atlanta.com SIP server is a type of SIP server known as a proxy
   server.  A proxy server receives SIP requests and forwards them on
   behalf of the requestor.  In this example, the proxy server receives
   the INVITE request and sends a 100 (Trying) response back to Alice's
   softphone.  The 100 (Trying) response indicates that the INVITE has
   been received and that the proxy is working on her behalf to route
   the INVITE to the destination.  Responses in SIP use a three-digit
   code followed by a descriptive phrase.  This response contains the
   same To, From, Call-ID, CSeq and branch parameter in the Via as the
   INVITE, which allows Alice's softphone to correlate this response to
   the sent INVITE.  The atlanta.com proxy server locates the proxy
   server at biloxi.com, possibly by performing a particular type of DNS
   (Domain Name Service) lookup to find the SIP server that serves the
   biloxi.com domain.  This is described in [4].  As a result, it
   obtains the IP address of the biloxi.com proxy server and forwards,
   or proxies, the INVITE request there.  Before forwarding the request,
   the atlanta.com proxy server adds an additional Via header field
   value that contains its own address (the INVITE already contains
   Alice's address in the first Via).  The biloxi.com proxy server
   receives the INVITE and responds with a 100 (Trying) response back to
   the atlanta.com proxy server to indicate that it has received the
   INVITE and is processing the request.  The proxy server consults a
   database, generically called a location service, that contains the
   current IP address of Bob.  (We shall see in the next section how
   this database can be populated.)  The biloxi.com proxy server adds
   another Via header field value with its own address to the INVITE and
   proxies it to Bob's SIP phone.

The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. (We shall see in the next section how this database can be populated.) The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone.

   Bob's SIP phone receives the INVITE and alerts Bob to the incoming
   call from Alice so that Bob can decide whether to answer the call,
   that is, Bob's phone rings.  Bob's SIP phone indicates this in a 180
   (Ringing) response, which is routed back through the two proxies in
   the reverse direction.  Each proxy uses the Via header field to
   determine where to send the response and removes its own address from
   the top.  As a result, although DNS and location service lookups were
   required to route the initial INVITE, the 180 (Ringing) response can
   be returned to the caller without lookups or without state being

Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being

Rosenberg, et. al.          Standards Track                    [Page 14]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 14] RFC 3261 SIP: Session Initiation Protocol June 2002

   maintained in the proxies.  This also has the desirable property that
   each proxy that sees the INVITE will also see all responses to the
   INVITE.

maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE.

   When Alice's softphone receives the 180 (Ringing) response, it passes
   this information to Alice, perhaps using an audio ringback tone or by
   displaying a message on Alice's screen.

When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen.

   In this example, Bob decides to answer the call.  When he picks up
   the handset, his SIP phone sends a 200 (OK) response to indicate that
   the call has been answered.  The 200 (OK) contains a message body
   with the SDP media description of the type of session that Bob is
   willing to establish with Alice.  As a result, there is a two-phase
   exchange of SDP messages: Alice sent one to Bob, and Bob sent one
   back to Alice.  This two-phase exchange provides basic negotiation
   capabilities and is based on a simple offer/answer model of SDP
   exchange.  If Bob did not wish to answer the call or was busy on
   another call, an error response would have been sent instead of the
   200 (OK), which would have resulted in no media session being
   established.  The complete list of SIP response codes is in Section
   21.  The 200 (OK) (message F9 in Figure 1) might look like this as
   Bob sends it out:

In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The complete list of SIP response codes is in Section 21. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out:

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP server10.biloxi.com
         ;branch=z9hG4bKnashds8;received=192.0.2.3
      Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
         ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
      Via: SIP/2.0/UDP pc33.atlanta.com
         ;branch=z9hG4bK776asdhds ;received=192.0.2.1
      To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710@pc33.atlanta.com
      CSeq: 314159 INVITE
      Contact: <sip:bob@192.0.2.4>
      Content-Type: application/sdp
      Content-Length: 131

SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131

      (Bob's SDP not shown)

(Bob's SDP not shown)

   The first line of the response contains the response code (200) and
   the reason phrase (OK).  The remaining lines contain header fields.
   The Via, To, From, Call-ID, and CSeq header fields are copied from
   the INVITE request.  (There are three Via header field values - one
   added by Alice's SIP phone, one added by the atlanta.com proxy, and
   one added by the biloxi.com proxy.)  Bob's SIP phone has added a tag
   parameter to the To header field.  This tag will be incorporated by
   both endpoints into the dialog and will be included in all future

The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob's SIP phone has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future

Rosenberg, et. al.          Standards Track                    [Page 15]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 15] RFC 3261 SIP: Session Initiation Protocol June 2002

   requests and responses in this call.  The Contact header field
   contains a URI at which Bob can be directly reached at his SIP phone.
   The Content-Type and Content-Length refer to the message body (not
   shown) that contains Bob's SDP media information.

requests and responses in this call. The Contact header field contains a URI at which Bob can be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information.

   In addition to DNS and location service lookups shown in this
   example, proxy servers can make flexible "routing decisions" to
   decide where to send a request.  For example, if Bob's SIP phone
   returned a 486 (Busy Here) response, the biloxi.com proxy server
   could proxy the INVITE to Bob's voicemail server.  A proxy server can
   also send an INVITE to a number of locations at the same time.  This
   type of parallel search is known as forking.

In addition to DNS and location service lookups shown in this example, proxy servers can make flexible "routing decisions" to decide where to send a request. For example, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob's voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking.

   In this case, the 200 (OK) is routed back through the two proxies and
   is received by Alice's softphone, which then stops the ringback tone
   and indicates that the call has been answered.  Finally, Alice's
   softphone sends an acknowledgement message, ACK, to Bob's SIP phone
   to confirm the reception of the final response (200 (OK)).  In this
   example, the ACK is sent directly from Alice's softphone to Bob's SIP
   phone, bypassing the two proxies.  This occurs because the endpoints
   have learned each other's address from the Contact header fields
   through the INVITE/200 (OK) exchange, which was not known when the
   initial INVITE was sent.  The lookups performed by the two proxies
   are no longer needed, so the proxies drop out of the call flow.  This
   completes the INVITE/200/ACK three-way handshake used to establish
   SIP sessions.  Full details on session setup are in Section 13.

In this case, the 200 (OK) is routed back through the two proxies and is received by Alice's softphone, which then stops the ringback tone and indicates that the call has been answered. Finally, Alice's softphone sends an acknowledgement message, ACK, to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13.

   Alice and Bob's media session has now begun, and they send media
   packets using the format to which they agreed in the exchange of SDP.
   In general, the end-to-end media packets take a different path from
   the SIP signaling messages.

Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages.

   During the session, either Alice or Bob may decide to change the
   characteristics of the media session.  This is accomplished by
   sending a re-INVITE containing a new media description.  This re-
   INVITE references the existing dialog so that the other party knows
   that it is to modify an existing session instead of establishing a
   new session.  The other party sends a 200 (OK) to accept the change.
   The requestor responds to the 200 (OK) with an ACK.  If the other
   party does not accept the change, he sends an error response such as
   488 (Not Acceptable Here), which also receives an ACK.  However, the
   failure of the re-INVITE does not cause the existing call to fail -
   the session continues using the previously negotiated
   characteristics.  Full details on session modification are in Section
   14.

During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14.

Rosenberg, et. al.          Standards Track                    [Page 16]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[16ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   At the end of the call, Bob disconnects (hangs up) first and
   generates a BYE message.  This BYE is routed directly to Alice's
   softphone, again bypassing the proxies.  Alice confirms receipt of
   the BYE with a 200 (OK) response, which terminates the session and
   the BYE transaction.  No ACK is sent - an ACK is only sent in
   response to a response to an INVITE request.  The reasons for this
   special handling for INVITE will be discussed later, but relate to
   the reliability mechanisms in SIP, the length of time it can take for
   a ringing phone to be answered, and forking.  For this reason,
   request handling in SIP is often classified as either INVITE or non-
   INVITE, referring to all other methods besides INVITE.  Full details
   on session termination are in Section 15.

呼び出しの終わりに、ボブは、最初に、切断して(掛けます)、BYEメッセージを生成します。 再びプロキシを迂回させて、このBYEは直接アリスのソフトフォンに発送されます。 アリスはセッションとBYEトランザクションを終える200(OK)応答があるBYEの領収書を確認します。 ACKを全く送りません--INVITE要求への応答に対応してACKを送るだけです。 SIP、鳴る電話が出られるにはかかるかもしれない時間の長さ、および分岐で信頼性のメカニズムに関連するのを除いて、後でこのINVITEに、特別な取り扱いの理由について議論するでしょう。 この理由で、SIPの取り扱いがINVITEか非INVITEのどちらかとしてしばしば分類されるよう要求してください、INVITE以外に他のすべてのメソッドを示して。 セッション終了での一部始終がセクション15にあります。

   Section 24.2 describes the messages shown in Figure 1 in full.

セクション24.2は全部の図1に示されたメッセージについて説明します。

   In some cases, it may be useful for proxies in the SIP signaling path
   to see all the messaging between the endpoints for the duration of
   the session.  For example, if the biloxi.com proxy server wished to
   remain in the SIP messaging path beyond the initial INVITE, it would
   add to the INVITE a required routing header field known as Record-
   Route that contained a URI resolving to the hostname or IP address of
   the proxy.  This information would be received by both Bob's SIP
   phone and (due to the Record-Route header field being passed back in
   the 200 (OK)) Alice's softphone and stored for the duration of the
   dialog.  The biloxi.com proxy server would then receive and proxy the
   ACK, BYE, and 200 (OK) to the BYE.  Each proxy can independently
   decide to receive subsequent messages, and those messages will pass
   through all proxies that elect to receive it.  This capability is
   frequently used for proxies that are providing mid-call features.

いくつかの場合、SIPシグナリング経路のプロキシがセッションの持続時間に関して終点の間のすべてのメッセージングを見るのは、役に立つかもしれません。 例えば、biloxi.comプロキシサーバであるなら、初期のINVITEを超えたSIPメッセージング経路に残っていることが願われている場合、それは必要なプロキシがホスト名に決議するURIを含んだRecordルートかIPアドレスとして知られているルーティングヘッダーフィールドをINVITEに加えるでしょう。 この情報は、ボブのSIP電話と(200(OK)で戻されるRecord-ルートヘッダーフィールドによる)アリスのソフトフォンの両方によって受け取られて、対話の持続時間のために保存されるでしょう。 次に、biloxi.comプロキシサーバが受信されるだろう、プロキシ、BYEへのACK、BYE、および200(OK)。 各プロキシは、その後のメッセージを受け取ると独自に決めることができます、そして、それらのメッセージはそれを受けるのを選ぶすべてのプロキシを通り抜けるでしょう。 この能力は中間の繰り上げ償還条項を提供しているプロキシに頻繁に使用されます。

   Registration is another common operation in SIP.  Registration is one
   way that the biloxi.com server can learn the current location of Bob.
   Upon initialization, and at periodic intervals, Bob's SIP phone sends
   REGISTER messages to a server in the biloxi.com domain known as a SIP
   registrar.  The REGISTER messages associate Bob's SIP or SIPS URI
   (sip:bob@biloxi.com) with the machine into which he is currently
   logged (conveyed as a SIP or SIPS URI in the Contact header field).
   The registrar writes this association, also called a binding, to a
   database, called the location service, where it can be used by the
   proxy in the biloxi.com domain.  Often, a registrar server for a
   domain is co-located with the proxy for that domain.  It is an
   important concept that the distinction between types of SIP servers
   is logical, not physical.

登録はSIPでの別の一般的な操作です。 登録はbiloxi.comサーバがボブの現在の位置を学ぶことができるある方法です。 初期化する、および周期的な間隔で、ボブのSIP電話はSIP記録係として知られているbiloxi.comドメインのサーバへのメッセージをREGISTERに送ります。 REGISTERメッセージは彼が現在登録される(SIPかSIPS URIとして、Contactヘッダーフィールドでは、運ばれます)マシンにボブのSIPかSIPS URI(一口: bob@biloxi.com )を関連づけます。 記録係はまた、結合と呼ばれるこの協会に書きます、biloxi.comドメインのプロキシがそれを使用できる位置のサービスと呼ばれるデータベースに。 しばしば、ドメインへの記録係サーバはそのドメインへのプロキシと共に共同見つけられています。 それはSIPサーバのタイプの区別が物理的であるのではなく、論理的であるという重要な概念です。

   Bob is not limited to registering from a single device.  For example,
   both his SIP phone at home and the one in the office could send
   registrations.  This information is stored together in the location

ボブは単一のデバイスから登録するのに制限されません。 例えば、ホームの彼のSIP電話とオフィスのものの両方が登録証明書を送るかもしれません。 この情報は位置に一緒に保存されます。

Rosenberg, et. al.          Standards Track                    [Page 17]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[17ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   service and allows a proxy to perform various types of searches to
   locate Bob.  Similarly, more than one user can be registered on a
   single device at the same time.

プロキシがボブの居場所を見つけるように様々なタイプの検索を実行するのを修理して、許容します。 同様に、同時に、単一のデバイスに1人以上のユーザを登録できます。

   The location service is just an abstract concept.  It generally
   contains information that allows a proxy to input a URI and receive a
   set of zero or more URIs that tell the proxy where to send the
   request.  Registrations are one way to create this information, but
   not the only way.  Arbitrary mapping functions can be configured at
   the discretion of the administrator.

位置のサービスはただ抽象概念です。 一般に、それはプロキシがURIを入力して、1セットのゼロを受け取るのを許容するか、またはどこかをプロキシに言うより多くのURIが要求を送るのを許容する情報を含んでいます。 登録証明書は、この情報を作成することにおいて一方通行ですが、唯一の方法で一方通行であるというわけではありません。 管理者の裁量で任意のマッピング機能を構成できます。

   Finally, it is important to note that in SIP, registration is used
   for routing incoming SIP requests and has no role in authorizing
   outgoing requests.  Authorization and authentication are handled in
   SIP either on a request-by-request basis with a challenge/response
   mechanism, or by using a lower layer scheme as discussed in Section
   26.

最終的に、登録がSIPでは、入って来るSIPが要求するルーティングに使用されて、送信する要求を認可する際に役割を全く持っていないことに注意するのは重要です。 承認と認証は、SIPで挑戦/反応機構がある要求による要求ベース、またはセクション26で議論するように下層体系を使用することによって、扱われます。

   The complete set of SIP message details for this registration example
   is in Section 24.1.

この登録の例のためのSIPの完全なメッセージ細部がセクション24.1にあります。

   Additional operations in SIP, such as querying for the capabilities
   of a SIP server or client using OPTIONS, or canceling a pending
   request using CANCEL, will be introduced in later sections.

後のセクションでSIPサーバかクライアントがOPTIONSを使用するか、または取り消す能力のためにキャンセルを使用する未定の要求について質問などなどのSIPの兼業を導入するでしょう。

5 Structure of the Protocol

5 プロトコルの構造

   SIP is structured as a layered protocol, which means that its
   behavior is described in terms of a set of fairly independent
   processing stages with only a loose coupling between each stage.  The
   protocol behavior is described as layers for the purpose of
   presentation, allowing the description of functions common across
   elements in a single section.  It does not dictate an implementation
   in any way.  When we say that an element "contains" a layer, we mean
   it is compliant to the set of rules defined by that layer.

SIPは層にされたプロトコルとして構造化されます。(それは、各ステージの間には、疎結合しかなく振舞いが1セットのかなり独立している処理台で説明されることを意味します)。 プロトコルの振舞いはプレゼンテーションの目的のために層として記述されています、1つのセクションの要素の向こう側に一般的な機能の記述を許容して。 それは何らかの方法で実装を書き取りません。 要素が層を「含む」と言うとき、私たちは、それがその層で定義された規則のセットに言いなりになると言っています。

   Not every element specified by the protocol contains every layer.
   Furthermore, the elements specified by SIP are logical elements, not
   physical ones.  A physical realization can choose to act as different
   logical elements, perhaps even on a transaction-by-transaction basis.

プロトコルによって指定されたあらゆる要素があらゆる層を含むというわけではありません。 その上、SIPによって指定された要素は物理的なものではなく、論理要素です。 物理的な実現は、異なった論理要素としてトランザクションごとの恐らくベースにさえ機能するのを選ぶことができます。

   The lowest layer of SIP is its syntax and encoding.  Its encoding is
   specified using an augmented Backus-Naur Form grammar (BNF).  The
   complete BNF is specified in Section 25; an overview of a SIP
   message's structure can be found in Section 7.

SIPの最も低い層は、その構文とコード化です。 コード化は、増大しているバッカス記法文法(BNF)を使用することで指定されます。 完全なBNFはセクション25で指定されます。 セクション7でSIPメッセージの構造の概要を見つけることができます。

Rosenberg, et. al.          Standards Track                    [Page 18]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[18ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The second layer is the transport layer.  It defines how a client
   sends requests and receives responses and how a server receives
   requests and sends responses over the network.  All SIP elements
   contain a transport layer.  The transport layer is described in
   Section 18.

2番目の層はトランスポート層です。 それは、サーバがどのようにネットワークの上にクライアントがどのように要求を送って、応答を受けるか、そして、要求を受け取って、応答を送るかを定義します。 すべてのSIP要素がトランスポート層を含んでいます。 トランスポート層はセクション18で説明されます。

   The third layer is the transaction layer.  Transactions are a
   fundamental component of SIP.  A transaction is a request sent by a
   client transaction (using the transport layer) to a server
   transaction, along with all responses to that request sent from the
   server transaction back to the client.  The transaction layer handles
   application-layer retransmissions, matching of responses to requests,
   and application-layer timeouts.  Any task that a user agent client
   (UAC) accomplishes takes place using a series of transactions.
   Discussion of transactions can be found in Section 17.  User agents
   contain a transaction layer, as do stateful proxies.  Stateless
   proxies do not contain a transaction layer.  The transaction layer
   has a client component (referred to as a client transaction) and a
   server component (referred to as a server transaction), each of which
   are represented by a finite state machine that is constructed to
   process a particular request.

3番目の層はトランザクション層です。 トランザクションはSIPの基本要素です。 トランザクションはサーバトランザクションへのクライアントトランザクション(トランスポート層を使用する)によって送られた要求です、サーバトランザクションからクライアントに送って戻されたその要求へのすべての応答と共に。 トランザクション層は応用層「再-トランスミッション」、要求への応答のマッチング、および応用層タイムアウトを扱います。 ユーザエージェントクライアント(UAC)が達成するどんなタスクも、一連のトランザクションを使用することで行われます。 セクション17でトランザクションの議論を見つけることができます。 ユーザエージェントはstatefulプロキシのようにトランザクション層を含みます。 状態がないプロキシはトランザクション層を含んでいません。 トランザクション層には、クライアントコンポーネント(クライアントトランザクションと呼ばれる)とサーバコンポーネント(サーバトランザクションと呼ばれる)があります。それは特定の要求を処理するために組み立てられる有限状態機械によってそれぞれ表されます。

   The layer above the transaction layer is called the transaction user
   (TU).  Each of the SIP entities, except the stateless proxy, is a
   transaction user.  When a TU wishes to send a request, it creates a
   client transaction instance and passes it the request along with the
   destination IP address, port, and transport to which to send the
   request.  A TU that creates a client transaction can also cancel it.
   When a client cancels a transaction, it requests that the server stop
   further processing, revert to the state that existed before the
   transaction was initiated, and generate a specific error response to
   that transaction.  This is done with a CANCEL request, which
   constitutes its own transaction, but references the transaction to be
   cancelled (Section 9).

トランザクション層の上の層はトランザクションユーザ(TU)と呼ばれます。 それぞれのSIP実体は状態がないプロキシ以外のトランザクションユーザです。 TUが要求を送りたがっているとき、それは、要求を送る送付先IPアドレス、ポート、および輸送と共にクライアントトランザクションインスタンスを作成して、要求にそれに合格します。 また、クライアントトランザクションを作成するTUはそれを取り消すことができます。 クライアントがトランザクションを取り消すとき、それは、サーバが、より遠い処理を止めて、トランザクションが開始される前に存在した状態に戻って、そのトランザクションへの特定の誤り応答を生成するよう要求します。 キャンセル要求でこれをして、唯一の参照は取り消されるべきトランザクション(セクション9)です。(要求はそれ自身のトランザクションを構成します)。

   The SIP elements, that is, user agent clients and servers, stateless
   and stateful proxies and registrars, contain a core that
   distinguishes them from each other.  Cores, except for the stateless
   proxy, are transaction users.  While the behavior of the UAC and UAS
   cores depends on the method, there are some common rules for all
   methods (Section 8).  For a UAC, these rules govern the construction
   of a request; for a UAS, they govern the processing of a request and
   generating a response.  Since registrations play an important role in
   SIP, a UAS that handles a REGISTER is given the special name
   registrar.  Section 10 describes UAC and UAS core behavior for the
   REGISTER method.  Section 11 describes UAC and UAS core behavior for
   the OPTIONS method, used for determining the capabilities of a UA.

SIP要素(すなわち、ユーザエージェントのクライアント、サーバ、状態がなくてstatefulなプロキシ、および記録係)は、互いと彼らを区別するコアを含んでいます。 コアは状態がないプロキシ以外のトランザクションユーザです。 UACとUASコアの振舞いはメソッドによりますが、すべてのメソッド(セクション8)のためのいくつかの共通規則があります。 UACに関しては、これらの規則は要求の工事を治めます。 UASに関しては、彼らは要求と応答を生成する処理を治めます。 登録証明書がSIPで重要な役割を果たすので、記録係という特別な名前をREGISTERを扱うUASに与えます。 セクション10はREGISTERメソッドのためのUACとUASコアの振舞いについて説明します。 セクション11はUACとUAの能力を決定するのに使用されるOPTIONSメソッドのためのUASコアの振舞いについて説明します。

Rosenberg, et. al.          Standards Track                    [Page 19]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[19ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Certain other requests are sent within a dialog.  A dialog is a
   peer-to-peer SIP relationship between two user agents that persists
   for some time.  The dialog facilitates sequencing of messages and
   proper routing of requests between the user agents.  The INVITE
   method is the only way defined in this specification to establish a
   dialog.  When a UAC sends a request that is within the context of a
   dialog, it follows the common UAC rules as discussed in Section 8 but
   also the rules for mid-dialog requests.  Section 12 discusses dialogs
   and presents the procedures for their construction and maintenance,
   in addition to construction of requests within a dialog.

対話の中で他のある要求を送ります。 対話は2人のユーザエージェントの間のしばらく持続するピアツーピアSIP関係です。 対話はユーザエージェントの間のメッセージの配列と要求の適切なルーティングを容易にします。 INVITEメソッドは対話を証明するためにこの仕様に基づき定義された唯一の道です。 UACが対話の文脈の中にある要求を送るとき、それは中間の対話要求のためのセクション8にもかかわらず、規則でも議論するように一般的なUAC規則に従います。 セクション12は、彼らの工事とメインテナンスのために対話について論じて、手順を提示します、対話の中の要求の工事に加えて。

   The most important method in SIP is the INVITE method, which is used
   to establish a session between participants.  A session is a
   collection of participants, and streams of media between them, for
   the purposes of communication.  Section 13 discusses how sessions are
   initiated, resulting in one or more SIP dialogs.  Section 14
   discusses how characteristics of that session are modified through
   the use of an INVITE request within a dialog.  Finally, section 15
   discusses how a session is terminated.

SIPで最も重要なメソッドはINVITEメソッドです。(そのメソッドは、関係者の間のセッションを証明するのに使用されます)。 セッションは、関係者の収集と、コミュニケーションの目的のためのそれらの間のメディアの流れです。 セクション13は1つ以上のSIP対話をもたらして、セッションがどう開始されるかを論じます。 セクション14はそのセッションの特性が対話の中でINVITE要求の使用でどう変更されるかを論じます。 最終的に、セクション15はセッションがどう終えられるかを論じます。

   The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
   entirely with the UA core (Section 9 describes cancellation, which
   applies to both UA core and proxy core).  Section 16 discusses the
   proxy element, which facilitates routing of messages between user
   agents.

セクション8、10、11、12、13、14、および15の手順はUAコアに完全に対処します(セクション9はUAコアとプロキシコアの両方に適用されるキャンセルについて説明します)。 セクション16はプロキシ要素について論じます。(それは、ユーザエージェントの間のメッセージのルーティングを容易にします)。

6 Definitions

6つの定義

   The following terms have special significance for SIP.

次の用語には、SIPに、特別な意味があります。

      Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
         that points to a domain with a location service that can map
         the URI to another URI where the user might be available.
         Typically, the location service is populated through
         registrations.  An AOR is frequently thought of as the "public
         address" of the user.

記録されている住所: 記録されている住所(AOR)は、別のURIにURIを写像できる位置のサービスがあるドメインをユーザが入手できるかもしれないところに示すSIPかSIPS URIです。 登録証明書で通常、位置のサービスは居住されます。 AORはユーザの「場内放送」として頻繁に考えられます。

      Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
         logical entity that receives a request and processes it as a
         user agent server (UAS).  In order to determine how the request
         should be answered, it acts as a user agent client (UAC) and
         generates requests.  Unlike a proxy server, it maintains dialog
         state and must participate in all requests sent on the dialogs
         it has established.  Since it is a concatenation of a UAC and
         UAS, no explicit definitions are needed for its behavior.

背中合わせのユーザエージェント: 背中合わせのユーザエージェント(B2BUA)は、要求を受け取る論理的な実体であり、ユーザエージェントサーバとしてそれを処理します(UAS)。 要求がどのように答えられるべきであるかを決定するために、それは、ユーザエージェントクライアント(UAC)として機能して、要求を生成します。 プロキシサーバと異なって、それは、対話状態を維持して、それが確立した対話で送られたすべての要求に参加しなければなりません。 それがUACとUASの連結であるので、どんな明白な定義も振舞いに必要ではありません。

Rosenberg, et. al.          Standards Track                    [Page 20]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[20ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      Call: A call is an informal term that refers to some communication
         between peers, generally set up for the purposes of a
         multimedia conversation.

以下に電話をしてください。 呼び出しは同輩(一般にマルチメディアの会話の目的のために上がっているセット)の何らかのコミュニケーションを示す非公式の用語です。

      Call Leg: Another name for a dialog [31]; no longer used in this
         specification.

脚に電話をしてください: 対話[31]のための別の名前。 もうこの仕様で使用されていません。

      Call Stateful: A proxy is call stateful if it retains state for a
         dialog from the initiating INVITE to the terminating BYE
         request.  A call stateful proxy is always transaction stateful,
         but the converse is not necessarily true.

Statefulに電話をしてください: 開始しているINVITEからBYEが要求する終わりまで対話のための状態を保有するなら、プロキシは呼び出しstatefulです。 呼び出しstatefulプロキシはいつもトランザクションstatefulですが、逆は必ず本当であるというわけではありません。

      Client: A client is any network element that sends SIP requests
         and receives SIP responses.  Clients may or may not interact
         directly with a human user.  User agent clients and proxies are
         clients.

クライアント: クライアントは要求をSIPに送って、SIP応答を受けるあらゆるネットワーク要素です。 クライアントは直接人間のユーザと対話するかもしれません。 ユーザエージェントのクライアントとプロキシはクライアントです。

      Conference: A multimedia session (see below) that contains
         multiple participants.

コンファレンス: 複数の関係者を含むマルチメディアセッション(以下を見ます)。

      Core: Core designates the functions specific to a particular type
         of SIP entity, i.e., specific to either a stateful or stateless
         proxy, a user agent or registrar.  All cores, except those for
         the stateless proxy, are transaction users.

コア: コアは特定のタイプのSIP実体に特定の、そして、すなわち、statefulか状態がないプロキシのどちらかに、特定の機能、ユーザエージェントまたは記録係を任命します。 状態がないプロキシのためのそれら以外のすべてのコアがトランザクションユーザです。

      Dialog: A dialog is a peer-to-peer SIP relationship between two
         UAs that persists for some time.  A dialog is established by
         SIP messages, such as a 2xx response to an INVITE request.  A
         dialog is identified by a call identifier, local tag, and a
         remote tag.  A dialog was formerly known as a call leg in RFC
         2543.

対話: 対話はしばらく固執する2UAsの間のピアツーピアSIP関係です。 対話はINVITE要求への2xx応答などのSIPメッセージによって確立されます。 対話は呼び出し識別子、地方のタグ、およびリモートタグによって特定されます。 対話は以前、RFC2543の呼び出し脚として知られていました。

      Downstream: A direction of message forwarding within a transaction
         that refers to the direction that requests flow from the user
         agent client to user agent server.

川下: トランザクションの中でそれを進めるメッセージの方向はユーザエージェントのクライアントからユーザエージェントサーバまでの流れを要求する方向を示します。

      Final Response: A response that terminates a SIP transaction, as
         opposed to a provisional response that does not.  All 2xx, 3xx,
         4xx, 5xx and 6xx responses are final.

最終的な応答: 暫定的なそうしない応答と対照的にSIPトランザクションを終える応答。 すべての2xx、3xx、4xx、5xx、および6xx応答は最終的です。

      Header: A header is a component of a SIP message that conveys
         information about the message.  It is structured as a sequence
         of header fields.

ヘッダー: ヘッダーはメッセージに関して情報を伝達するSIPメッセージの成分です。 それはヘッダーフィールドの系列として構造化されます。

      Header Field: A header field is a component of the SIP message
         header.  A header field can appear as one or more header field
         rows. Header field rows consist of a header field name and zero
         or more header field values. Multiple header field values on a

ヘッダーフィールド: ヘッダーフィールドはSIPメッセージヘッダーの部品です。 1つ以上のヘッダーフィールドが船をこぐとき、ヘッダーフィールドは現れることができます。 ヘッダーフィールド行はヘッダーフィールド名とゼロか、より多くのヘッダーフィールド値から成ります。 aの複数のヘッダーフィールド値

Rosenberg, et. al.          Standards Track                    [Page 21]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[21ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         given header field row are separated by commas. Some header
         fields can only have a single header field value, and as a
         result, always appear as a single header field row.

与えられたヘッダーフィールド行はコンマによって切り離されます。 いくつかのヘッダーフィールドが、ただ一つのヘッダーフィールド値を持つだけであり、ただ一つのヘッダーフィールド行としてその結果、そして、いつも現れることができます。

      Header Field Value: A header field value is a single value; a
         header field consists of zero or more header field values.

ヘッダーフィールド値: ヘッダーフィールド値はただ一つの値です。 ヘッダーフィールドはゼロか、より多くのヘッダーフィールド値から成ります。

      Home Domain: The domain providing service to a SIP user.
         Typically, this is the domain present in the URI in the
         address-of-record of a registration.

ホームドメイン: SIPユーザに対するサービスを提供するドメイン。 これは通常、登録の記録されている住所のURIにおける現在のドメインです。

      Informational Response: Same as a provisional response.

情報の応答: 暫定的な応答と同じです。

      Initiator, Calling Party, Caller: The party initiating a session
         (and dialog) with an INVITE request.  A caller retains this
         role from the time it sends the initial INVITE that established
         a dialog until the termination of that dialog.

創始者、起呼側、訪問者: INVITE要求とのセッション(そして、対話)を開始するパーティー。 訪問者はそれが対話を確立した初期のINVITEを送る時からその対話の終了までこの役割を保有します。

      Invitation: An INVITE request.

招待: INVITE要求。

      Invitee, Invited User, Called Party, Callee: The party that
         receives an INVITE request for the purpose of establishing a
         new session.  A callee retains this role from the time it
         receives the INVITE until the termination of the dialog
         established by that INVITE.

招待参加者(招待されたユーザ)は、パーティ、訪問される人と呼びました: INVITEを受け取るパーティーは設立の目的のために新しいセッションを要求します。 訪問される人はそれがINVITEを受ける時からそのINVITEによって確立された対話の終了までこの役割を保有します。

      Location Service: A location service is used by a SIP redirect or
         proxy server to obtain information about a callee's possible
         location(s).  It contains a list of bindings of address-of-
         record keys to zero or more contact addresses.  The bindings
         can be created and removed in many ways; this specification
         defines a REGISTER method that updates the bindings.

位置のサービス: 位置のサービスは再直接でSIPによって利用されます。または、訪問される人の可能な位置の情報を得るプロキシサーバ。 それはアドレスの製本のリストを含んでいます。-記録キーでは、ゼロか以上にアドレスに連絡してください。 様々な意味で結合を作成して、取り除くことができます。 この仕様は結合をアップデートするREGISTERメソッドを定義します。

      Loop: A request that arrives at a proxy, is forwarded, and later
         arrives back at the same proxy.  When it arrives the second
         time, its Request-URI is identical to the first time, and other
         header fields that affect proxy operation are unchanged, so
         that the proxy would make the same processing decision on the
         request it made the first time.  Looped requests are errors,
         and the procedures for detecting them and handling them are
         described by the protocol.

以下を輪にしてください。 プロキシに到着して、転送されて、後で同じプロキシに到着して戻る要求。 2回目に到着するとき、Request-URIは1回目と同じです、そして、プロキシ操作に影響する他のヘッダーフィールドは変わりがありません、プロキシがそれが1回目にした要求の同じ処理決定をするように。 輪にされた要求は誤りです、そして、それらを検出して、それらを扱うための手順はプロトコルによって説明されます。

      Loose Routing: A proxy is said to be loose routing if it follows
         the procedures defined in this specification for processing of
         the Route header field.  These procedures separate the
         destination of the request (present in the Request-URI) from

ルート設定を発射してください: Routeヘッダーフィールドの処理のためのこの仕様に基づき定義された手順に従うなら、プロキシはゆるいルーティングであると言われます。 これらの手順は要求(中では、Request-URIを提示する)の目的地を切り離します。

Rosenberg, et. al.          Standards Track                    [Page 22]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[22ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         the set of proxies that need to be visited along the way
         (present in the Route header field).  A proxy compliant to
         these mechanisms is also known as a loose router.

道(Routeヘッダーフィールドで現在の)に沿って訪問される必要があるプロキシのセット。 また、これらのメカニズムに言いなりになっているプロキシはゆるいルータとして知られています。

      Message: Data sent between SIP elements as part of the protocol.
         SIP messages are either requests or responses.

メッセージ: データはプロトコルの一部としてSIP要素の間で発信しました。 SIPメッセージは、要求か応答のどちらかです。

      Method: The method is the primary function that a request is meant
         to invoke on a server.  The method is carried in the request
         message itself.  Example methods are INVITE and BYE.

メソッド: メソッドは要求がサーバに呼び出すことになっているプライマリ機能です。メソッドは要求メッセージ自体で運ばれます。 例のメソッドは、INVITEとBYEです。

      Outbound Proxy: A proxy that receives requests from a client, even
         though it may not be the server resolved by the Request-URI.
         Typically, a UA is manually configured with an outbound proxy,
         or can learn about one through auto-configuration protocols.

外国行きのプロキシ: それがRequest-URIによって決議されたサーバでないかもしれませんが、クライアントから要求を受け取るプロキシ。 UAは通常、外国行きのプロキシによって手動で構成されるか、または1時頃に自動構成プロトコルを通して学ぶことができます。

      Parallel Search: In a parallel search, a proxy issues several
         requests to possible user locations upon receiving an incoming
         request.  Rather than issuing one request and then waiting for
         the final response before issuing the next request as in a
         sequential search, a parallel search issues requests without
         waiting for the result of previous requests.

検索に沿ってください: 平行な検索では、入って来る要求を受け取るとき、プロキシは可能なユーザ位置にいくつかの要求を出します。 連続した検索のように次の要求を出す前に1つの要求を出して、次に、最終的な応答を待つよりむしろ、前の要求の結果を待たないで、平行な検索は要求を出します。

      Provisional Response: A response used by the server to indicate
         progress, but that does not terminate a SIP transaction.  1xx
         responses are provisional, other responses are considered
         final.

暫定的な応答: SIPトランザクションを終えないサーバによって使用される、進歩を示す応答。 1xx応答が暫定的である、他の応答は最終的であると考えられます。

      Proxy, Proxy Server: An intermediary entity that acts as both a
         server and a client for the purpose of making requests on
         behalf of other clients.  A proxy server primarily plays the
         role of routing, which means its job is to ensure that a
         request is sent to another entity "closer" to the targeted
         user.  Proxies are also useful for enforcing policy (for
         example, making sure a user is allowed to make a call).  A
         proxy interprets, and, if necessary, rewrites specific parts of
         a request message before forwarding it.

プロキシ、Proxyサーバ: 他のクライアントを代表して要求をする目的のためのサーバとクライアントの両方として機能する仲介者実体。 プロキシサーバは主としてルーティングの役割を果たします。(ルーティングは仕事が要求が「より近いところで狙っているユーザの」別の実体に送られるのを保証することであることを意味します)。 また、プロキシも方針を実施することの役に立ちます(例えば、確実にユーザを作ると、電話をかけることができます)。 プロキシは、解釈して、それを進める前に、必要なら、要求メッセージの特定の部分を書き直します。

      Recursion: A client recurses on a 3xx response when it generates a
         new request to one or more of the URIs in the Contact header
         field in the response.

再帰: それであるときに、3xx応答でのクライアント「再-呪い」は応答におけるContactヘッダーフィールドでURIの1つ以上に新しい要求を生成します。

      Redirect Server: A redirect server is a user agent server that
         generates 3xx responses to requests it receives, directing the
         client to contact an alternate set of URIs.

サーバを向け直してください: 再直接のサーバはそれが受け取る要求への3xx応答を生成するユーザエージェントサーバです、代替のセットのURIに連絡するようクライアントに指示して。

Rosenberg, et. al.          Standards Track                    [Page 23]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[23ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      Registrar: A registrar is a server that accepts REGISTER requests
         and places the information it receives in those requests into
         the location service for the domain it handles.

記録係: 記録係はREGISTER要求を受け入れて、それがそれらの要求にそれが扱うドメインのための位置のサービスに受け取る情報を置くサーバです。

      Regular Transaction: A regular transaction is any transaction with
         a method other than INVITE, ACK, or CANCEL.

普通取引: 普通取引はINVITE、ACK、またはキャンセル以外のメソッドがあるあらゆるトランザクションです。

      Request: A SIP message sent from a client to a server, for the
         purpose of invoking a particular operation.

以下を要求してください。 SIPメッセージは特定の操作を呼び出す目的のためにクライアントからサーバまで発信しました。

      Response: A SIP message sent from a server to a client, for
         indicating the status of a request sent from the client to the
         server.

応答: SIPメッセージはサーバからクライアントまで発信しました、要求の状態がクライアントからサーバまで発信したのを示すために。

      Ringback: Ringback is the signaling tone produced by the calling
         party's application indicating that a called party is being
         alerted (ringing).

Ringback: Ringbackは被呼者が警告されているのを示す起呼側のアプリケーション(鳴る)で作り出されたシグナリングトーンです。

      Route Set: A route set is a collection of ordered SIP or SIPS URI
         which represent a list of proxies that must be traversed when
         sending a particular request.  A route set can be learned,
         through headers like Record-Route, or it can be configured.

ルートはセットしました: ルートセットは特定の要求を送るとき横断しなければならないプロキシのリストを表す命令されたSIPかSIPS URIの収集です。 Record-ルートのようなヘッダーを通してルートセットについて学習できますか、またはそれを構成できます。

      Server: A server is a network element that receives requests in
         order to service them and sends back responses to those
         requests.  Examples of servers are proxies, user agent servers,
         redirect servers, and registrars.

サーバ: サーバはそれらを修理するために要求を受け取って、それらの要求への応答を返送するネットワーク要素です。 サーバに関する例は、プロキシと、ユーザエージェントサーバと、再直接のサーバと、記録係です。

      Sequential Search: In a sequential search, a proxy server attempts
         each contact address in sequence, proceeding to the next one
         only after the previous has generated a final response.  A 2xx
         or 6xx class final response always terminates a sequential
         search.

連続した検索: 連続した検索では、プロキシサーバは連続して各連絡先を試みて、前だったことの後にだけ次のものに続くのは最終的な応答を生成しました。 2xxか6xxのクラスの最終的な応答がいつも連続した検索を終えます。

      Session: From the SDP specification: "A multimedia session is a
         set of multimedia senders and receivers and the data streams
         flowing from senders to receivers.  A multimedia conference is
         an example of a multimedia session." (RFC 2327 [1]) (A session
         as defined for SDP can comprise one or more RTP sessions.)  As
         defined, a callee can be invited several times, by different
         calls, to the same session.  If SDP is used, a session is
         defined by the concatenation of the SDP user name, session id,
         network type, address type, and address elements in the origin
         field.

セッション: SDP仕様から: 「マルチメディアセッションは、1セットのマルチメディア送付者と受信機と送付者から受信機まで流れるデータ・ストリームです。」 「マルチメディア会議はマルチメディアセッションに関する例です。」 (RFC2327[1]) (SDPのために定義されるセッションは1つ以上のRTPセッションを包括できます。) 定義されるように、異なった呼び出しで同じセッションに訪問される人を何度か招待できます。 SDPが使用されているなら、セッションは発生源分野でSDPユーザ名、セッションイド、ネットワークタイプ、アドレスタイプ、およびアドレス要素の連結で定義されます。

      SIP Transaction: A SIP transaction occurs between a client and a
         server and comprises all messages from the first request sent
         from the client to the server up to a final (non-1xx) response

トランザクションをちびちび飲んでください: SIPトランザクションは、最終的な(非1xxの)応答までクライアントとサーバの間に起こって、クライアントからサーバに送られた最初の要求からすべてのメッセージを包括します。

Rosenberg, et. al.          Standards Track                    [Page 24]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[24ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         sent from the server to the client.  If the request is INVITE
         and the final response is a non-2xx, the transaction also
         includes an ACK to the response.  The ACK for a 2xx response to
         an INVITE request is a separate transaction.

サーバからクライアントまで発信しました。 また、要求がINVITEであり、最終的な応答が非2xxであるなら、トランザクションは応答にACKを含んでいます。 INVITE要求への2xx応答のためのACKは別々のトランザクションです。

      Spiral: A spiral is a SIP request that is routed to a proxy,
         forwarded onwards, and arrives once again at that proxy, but
         this time differs in a way that will result in a different
         processing decision than the original request.  Typically, this
         means that the request's Request-URI differs from its previous
         arrival.  A spiral is not an error condition, unlike a loop.  A
         typical cause for this is call forwarding.  A user calls
         joe@example.com.  The example.com proxy forwards it to Joe's
         PC, which in turn, forwards it to bob@example.com.  This
         request is proxied back to the example.com proxy.  However,
         this is not a loop.  Since the request is targeted at a
         different user, it is considered a spiral, and is a valid
         condition.

以下にらせん状に動かしてください。 らせんがそのプロキシに前方へ進められたプロキシに発送されて、もう一度到着するSIP要求ですが、今回はオリジナルの要求より異なった処理決定をもたらす方法で異なります。 通常、これは、要求のRequest-URIが前の到着と異なっていることを意味します。 らせんは輪と異なったエラー条件ではありません。 この典型的な原因は自動転送です。 ユーザは、 joe@example.com と呼びます。 example.comプロキシがジョーのPCにそれを送る、どれ、順番に、それを bob@example.com に送るか。 この要求はexample.comプロキシにproxiedして戻されます。 しかしながら、これは輪ではありません。 要求が異なったユーザをターゲットにするので、それは、らせんであると考えられて、有効な状態です。

      Stateful Proxy: A logical entity that maintains the client and
         server transaction state machines defined by this specification
         during the processing of a request, also known as a transaction
         stateful proxy.  The behavior of a stateful proxy is further
         defined in Section 16.  A (transaction) stateful proxy is not
         the same as a call stateful proxy.

Statefulプロキシ: クライアントを維持する論理的な実体と要求の処理の間、この仕様で定義されて、またトランザクションstatefulプロキシとして知られているサーバトランザクション州のマシン。 statefulプロキシの振舞いはセクション16でさらに定義されます。 (トランザクション)statefulプロキシは呼び出しstatefulプロキシと同じではありません。

      Stateless Proxy: A logical entity that does not maintain the
         client or server transaction state machines defined in this
         specification when it processes requests.  A stateless proxy
         forwards every request it receives downstream and every
         response it receives upstream.

状態がないプロキシ: クライアントかサーバトランザクション州のマシンを維持しない論理的な実体は、この仕様に基づきそれがいつ要求を処理するかを定義しました。 状態がないプロキシはそれが川下に受け取るあらゆる要求とそれが上流へ受けるあらゆる応答を進めます。

      Strict Routing: A proxy is said to be strict routing if it follows
         the Route processing rules of RFC 2543 and many prior work in
         progress versions of this RFC.  That rule caused proxies to
         destroy the contents of the Request-URI when a Route header
         field was present.  Strict routing behavior is not used in this
         specification, in favor of a loose routing behavior.  Proxies
         that perform strict routing are also known as strict routers.

厳しいルート設定: RFC2543のRoute処理規則とこのRFCの多くの先の処理中の作業バージョンに従うなら、プロキシは厳しいルーティングであると言われます。 Routeヘッダーフィールドが存在していたとき、その規則で、プロキシはRequest-URIのコンテンツを破壊しました。 厳しいルーティングの振舞いはゆるいルーティングの振舞いを支持してこの仕様で使用されません。 また、厳しいルーティングを実行するプロキシが厳しいルータとして知られています。

      Target Refresh Request: A target refresh request sent within a
         dialog is defined as a request that can modify the remote
         target of the dialog.

目標は要求をリフレッシュします: 目標は送って、中では、対話が対話のリモート目標を変更できる要求と定義されるという要求をリフレッシュします。

      Transaction User (TU): The layer of protocol processing that
         resides above the transaction layer.  Transaction users include
         the UAC core, UAS core, and proxy core.

トランザクションユーザ(TU): それを処理するプロトコルの層はトランザクション層を超えてあります。 トランザクションユーザはUACコア、UASコア、およびプロキシコアを入れます。

Rosenberg, et. al.          Standards Track                    [Page 25]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[25ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      Upstream: A direction of message forwarding within a transaction
         that refers to the direction that responses flow from the user
         agent server back to the user agent client.

上流: トランザクションの中でそれを進めるメッセージの方向は方向へのそのユーザエージェントサーバからユーザエージェントのクライアントまでの応答流動を参照します。

      URL-encoded: A character string encoded according to RFC 2396,
         Section 2.4 [5].

URLでコード化される: RFCによると、文字列はセクション2.4 2396、[5]をコード化しました。

      User Agent Client (UAC): A user agent client is a logical entity
         that creates a new request, and then uses the client
         transaction state machinery to send it.  The role of UAC lasts
         only for the duration of that transaction.  In other words, if
         a piece of software initiates a request, it acts as a UAC for
         the duration of that transaction.  If it receives a request
         later, it assumes the role of a user agent server for the
         processing of that transaction.

ユーザエージェントクライアント(UAC): ユーザエージェントのクライアントは、新しい要求を作成する論理的な実体であり、次に、それを送るのにクライアントトランザクション州の機械を使用します。 UACの役割はそのトランザクションの持続時間のためだけに持続します。 言い換えれば、ソフトウェア一本が要求を開始するなら、それはそのトランザクションの持続時間のためのUACとして機能します。 後で要求を受け取るなら、それはそのトランザクションの処理のためのユーザエージェントサーバの役割を引き受けます。

      UAC Core: The set of processing functions required of a UAC that
         reside above the transaction and transport layers.

UACコア: 処理機能のセットがトランザクションを超えて住んでいるUACとトランスポート層について必要です。

      User Agent Server (UAS): A user agent server is a logical entity
         that generates a response to a SIP request.  The response
         accepts, rejects, or redirects the request.  This role lasts
         only for the duration of that transaction.  In other words, if
         a piece of software responds to a request, it acts as a UAS for
         the duration of that transaction.  If it generates a request
         later, it assumes the role of a user agent client for the
         processing of that transaction.

ユーザエージェントサーバ(UAS): ユーザエージェントサーバはSIP要求への応答を生成する論理的な実体です。 応答は、要求を受け入れるか、拒絶するか、または向け直します。 この役割はそのトランザクションの持続時間のためだけに持続します。 言い換えれば、ソフトウェア一本が要求に応じるなら、それはそのトランザクションの持続時間のためのUASとして機能します。 後で要求を生成するなら、それはそのトランザクションの処理のためにユーザエージェントのクライアントの役割を引き受けます。

      UAS Core: The set of processing functions required at a UAS that
         resides above the transaction and transport layers.

UASコア: 処理機能のセットがトランザクションとトランスポート層を超えて住んでいるUASで必要です。

      User Agent (UA): A logical entity that can act as both a user
         agent client and user agent server.

ユーザエージェント(UA): 両方としてユーザエージェントのクライアントとユーザエージェントサーバを機能させることができる論理的な実体。

   The role of UAC and UAS, as well as proxy and redirect servers, are
   defined on a transaction-by-transaction basis.  For example, the user
   agent initiating a call acts as a UAC when sending the initial INVITE
   request and as a UAS when receiving a BYE request from the callee.
   Similarly, the same software can act as a proxy server for one
   request and as a redirect server for the next request.

UACの役割とプロキシと再直接のサーバと同様にUASはトランザクションごとのベースで定義されます。 訪問される人からBYE要求を受け取るとき、初期のINVITE要求とUASとして発信するとき、例えば、呼び出しを開始するユーザエージェントはUACとして務めます。 同様に、同じソフトウェアは1つの要求のためのプロキシサーバとして次の要求のための再直接のサーバとして作動できます。

   Proxy, location, and registrar servers defined above are logical
   entities; implementations MAY combine them into a single application.

上で定義されたプロキシ、位置、および記録係サーバは論理的な実体です。 実装はただ一つのアプリケーションにそれらを結合するかもしれません。

7 SIP Messages

7 一口メッセージ

   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
   [7]).

SIPはテキストベースのプロトコルであり、UTF-8 charsetを使用します。(RFC2279[7])。

Rosenberg, et. al.          Standards Track                    [Page 26]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[26ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   A SIP message is either a request from a client to a server, or a
   response from a server to a client.

SIPメッセージは、クライアントからサーバまでの要求かサーバからクライアントまで応答のどちらかです。

   Both Request (section 7.1) and Response (section 7.2) messages use
   the basic format of RFC 2822 [3], even though the syntax differs in
   character set and syntax specifics.  (SIP allows header fields that
   would not be valid RFC 2822 header fields, for example.)  Both types
   of messages consist of a start-line, one or more header fields, an
   empty line indicating the end of the header fields, and an optional
   message-body.

Request(セクション7.1)とResponse(セクション7.2)メッセージの両方がRFC2822[3]の基本形式を使用します、構文は文字集合と構文詳細において異なりますが。 (SIPは例えばRFC2822ヘッダーフィールドを有効でないヘッダーフィールドに許容します) 両方のタイプに関するメッセージはスタート系列、1つ以上のヘッダーフィールド、ヘッダーフィールドの終わりを示す空の系列、および任意のメッセージ本体から成ります。

         generic-message  =  start-line
                             *message-header
                             CRLF
                             [ message-body ]
         start-line       =  Request-Line / Status-Line

状態ジェネリックメッセージ=スタート系列*メッセージヘッダーCRLF[メッセージ本体]スタート系列=要求線/線

   The start-line, each message-header line, and the empty line MUST be
   terminated by a carriage-return line-feed sequence (CRLF).  Note that
   the empty line MUST be present even if the message-body is not.

復帰改行系列(CRLF)でスタート系列、それぞれのメッセージヘッダー系列、および空の系列を終えなければなりません。 メッセージ本体が存在していなくても空の系列が存在していなければならないことに注意してください。

   Except for the above difference in character sets, much of SIP's
   message and header field syntax is identical to HTTP/1.1.  Rather
   than repeating the syntax and semantics here, we use [HX.Y] to refer
   to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).

文字集合の上の違いを除いて、SIPのメッセージとヘッダーフィールド構文の多くがHTTP/1.1と同じです。 ここで構文と意味論を繰り返すよりむしろ、私たちは、現在のHTTP/1.1仕様のセクションX.Yについて言及するのに[HX.Y]を使用します。(RFC2616[8])。

   However, SIP is not an extension of HTTP.

しかしながら、SIPはHTTPの拡大ではありません。

7.1 Requests

7.1 要求

   SIP requests are distinguished by having a Request-Line for a start-
   line.  A Request-Line contains a method name, a Request-URI, and the
   protocol version separated by a single space (SP) character.

SIP要求は、スタート系列のためにRequest-線を持っていることによって、区別されます。 Request-線はメソッド名、Request-URI、およびシングルスペース(SP)キャラクタによって切り離されたプロトコルバージョンを含んでいます。

   The Request-Line ends with CRLF.  No CR or LF are allowed except in
   the end-of-line CRLF sequence.  No linear whitespace (LWS) is allowed
   in any of the elements.

CRLFがあるRequest-列の最後尾。 行の終わりのCRLF系列以外に、どんなCRもLFも許容されていません。 どんな直線的な空白(LWS)も要素のいずれにも許容されていません。

         Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

メソッドSP要求URI SP一口バージョン要求線=CRLF

      Method: This specification defines six methods: REGISTER for
           registering contact information, INVITE, ACK, and CANCEL for
           setting up sessions, BYE for terminating sessions, and
           OPTIONS for querying servers about their capabilities.  SIP
           extensions, documented in standards track RFCs, may define
           additional methods.

メソッド: この仕様は6つのメソッドを定義します: 彼らの能力の周りの問い合わせ先を登録するためのREGISTER、INVITE、ACK、セッションをセットアップするためのキャンセル、終わりセッションのためのBYE、およびサーバについて質問するためのOPTIONS。 標準化過程RFCsに記録されたSIP拡張子は追加メソッドを定義するかもしれません。

Rosenberg, et. al.          Standards Track                    [Page 27]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[27ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      Request-URI: The Request-URI is a SIP or SIPS URI as described in
           Section 19.1 or a general URI (RFC 2396 [5]).  It indicates
           the user or service to which this request is being addressed.
           The Request-URI MUST NOT contain unescaped spaces or control
           characters and MUST NOT be enclosed in "<>".

要求URI: Request-URIは、セクション19.1か一般的なURIで説明されるようにSIPかSIPS URIです。(RFC2396[5])。 それはこの要求が扱われているユーザかサービスを示します。 Request-URIは、非エスケープしている空間か制御文字を含んではいけなくて、「<>」に同封されてはいけません。

           SIP elements MAY support Request-URIs with schemes other than
           "sip" and "sips", for example the "tel" URI scheme of RFC
           2806 [9].  SIP elements MAY translate non-SIP URIs using any
           mechanism at their disposal, resulting in SIP URI, SIPS URI,
           or some other scheme.

SIP要素は「一口」と「一口」(例えば、RFC2806[9]の"tel"URI体系)を除いた体系でRequest-URIをサポートするかもしれません。 彼らの自由にどんなメカニズムも使用して、SIP要素は非SIP URIを翻訳するかもしれません、SIP URI、SIPS URI、またはある他の体系をもたらして。

      SIP-Version: Both request and response messages include the
           version of SIP in use, and follow [H3.1] (with HTTP replaced
           by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version
           ordering, compliance requirements, and upgrading of version
           numbers.  To be compliant with this specification,
           applications sending SIP messages MUST include a SIP-Version
           of "SIP/2.0".  The SIP-Version string is case-insensitive,
           but implementations MUST send upper-case.

一口バージョン: 要求と応答メッセージの両方が、バージョン番号のバージョン注文、承諾要件、およびアップグレードに関して使用中のSIPのバージョンを含んで、[H3.1]に続きます(SIPに取り替えて、SIP/2.0に取り替えて、HTTP/1.1に取り替えたHTTPで)。 この仕様で言いなりになるために、メッセージをSIPに送るアプリケーションは「一口/2インチ」のSIP-バージョンを含まなければなりません。 SIP-バージョンストリングは大文字と小文字を区別しないのですが、実装は大文字を送らなければなりません。

           Unlike HTTP/1.1, SIP treats the version number as a literal
           string.  In practice, this should make no difference.

HTTP/1.1と異なって、SIPは文字通りのストリングとしてバージョン番号を扱います。 実際には、これは重要であるべきではありません。

7.2 Responses

7.2 応答

   SIP responses are distinguished from requests by having a Status-Line
   as their start-line.  A Status-Line consists of the protocol version
   followed by a numeric Status-Code and its associated textual phrase,
   with each element separated by a single SP character.

SIP応答は、要求と彼らのスタート系列としてStatus-線を持っていることによって、区別されます。 Status-線は数値Status-コードとその関連原文の句があとに続いたプロトコルバージョンから成ります、各要素が単独のSPキャラクタによって切り離されている状態で。

   No CR or LF is allowed except in the final CRLF sequence.

最終的なCRLF系列以外に、どんなCRもLFも許容されていません。

      Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

状況表示行=一口バージョンSPステータスコードSP理由句のCRLF

   The Status-Code is a 3-digit integer result code that indicates the
   outcome of an attempt to understand and satisfy a request.  The
   Reason-Phrase is intended to give a short textual description of the
   Status-Code.  The Status-Code is intended for use by automata,
   whereas the Reason-Phrase is intended for the human user.  A client
   is not required to examine or display the Reason-Phrase.

Status-コードは要望を理解して、応じる試みの結果を示す3ケタの整数結果コードです。 Reason-句がStatus-コードの短い原文の記述を与えることを意図します。 Status-コードは使用のためにオートマトンで意図しますが、Reason-句は人間のユーザのために意図します。 クライアントは、Reason-句を調べるか、または表示するのに必要ではありません。

   While this specification suggests specific wording for the reason
   phrase, implementations MAY choose other text, for example, in the
   language indicated in the Accept-Language header field of the
   request.

この仕様が理由句のために特定の言葉遣いを示している間、例えば、実装は要求のAccept-言語ヘッダーフィールドで示された言語で他のテキストを選ぶかもしれません。

Rosenberg, et. al.          Standards Track                    [Page 28]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[28ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The first digit of the Status-Code defines the class of response.
   The last two digits do not have any categorization role.  For this
   reason, any response with a status code between 100 and 199 is
   referred to as a "1xx response", any response with a status code
   between 200 and 299 as a "2xx response", and so on.  SIP/2.0 allows
   six values for the first digit:

Status-コードの最初のケタは応答のクラスを定義します。 下2ケタには、どんな分類の役割もありません。 この理由で、ステータスコードが100と199の間あるどんな応答もステータスコードで「2xx応答」としての200と299の間などに「1xx応答」、どんな応答とも呼ばれます。 SIP/2.0は最初のケタのための6つの値を許容します:

      1xx: Provisional -- request received, continuing to process the
           request;

1xx: 暫定的です--要求を処理し続けていて、受け取られた要求;。

      2xx: Success -- the action was successfully received, understood,
           and accepted;

2xx: 成功--動作を首尾よく受けて、理解して、受け入れました。

      3xx: Redirection -- further action needs to be taken in order to
           complete the request;

3xx: リダイレクション--さらなる動作は、要求を終了するために取られる必要があります。

      4xx: Client Error -- the request contains bad syntax or cannot be
           fulfilled at this server;

4xx: クライアントError--要求が、誤りのある構文を含んでいるか、またはこのサーバで実現できません。

      5xx: Server Error -- the server failed to fulfill an apparently
           valid request;

5xx: サーバError--サーバは明らかに有効な要求を実現させませんでした。

      6xx: Global Failure -- the request cannot be fulfilled at any
           server.

6xx: グローバルなFailure--要求がどんなサーバでも実現できません。

   Section 21 defines these classes and describes the individual codes.

セクション21は、これらのクラスを定義して、個々のコードについて説明します。

7.3 Header Fields

7.3 ヘッダー分野

   SIP header fields are similar to HTTP header fields in both syntax
   and semantics.  In particular, SIP header fields follow the [H4.2]
   definitions of syntax for the message-header and the rules for
   extending header fields over multiple lines.  However, the latter is
   specified in HTTP with implicit whitespace and folding.  This
   specification conforms to RFC 2234 [10] and uses only explicit
   whitespace and folding as an integral part of the grammar.

SIPヘッダーフィールドは構文と意味論の両方のHTTPヘッダ分野と同様です。 特に、SIPヘッダーフィールドはメッセージヘッダーのための構文の[H4.2]定義と複数の系列の上でヘッダーフィールドを広げるための規則に従います。 しかしながら、後者は、暗黙の空白でHTTPで指定されていて折りたたみです。 この仕様は、2234[10]をRFCに従わせて、文法の不可欠の部分としての唯一の明白な空白と折り重なりを使用します。

   [H4.2] also specifies that multiple header fields of the same field
   name whose value is a comma-separated list can be combined into one
   header field.  That applies to SIP as well, but the specific rule is
   different because of the different grammars.  Specifically, any SIP
   header whose grammar is of the form

また、[H4.2]は、値がコンマで切り離されたリストである同じフィールド名の複数のヘッダーフィールドを1つのヘッダーフィールドに結合できると指定します。 それはまた、SIPに適用されますが、特定の規則は異なった文法で異なっています。 明確に文法がフォームのものであるどんなSIPヘッダー

      header  =  "header-name" HCOLON header-value *(COMMA header-value)

ヘッダー=「ヘッダー名」HCOLONヘッダー価値の*(COMMAヘッダー価値)

   allows for combining header fields of the same name into a comma-
   separated list.  The Contact header field allows a comma-separated
   list unless the header field value is "*".

コンマの切り離されたリストの中に同じ名前のヘッダーフィールドを結合するために、許容します。 Contactヘッダーフィールドはヘッダーフィールド値が「*」でないならコンマで切り離されたリストを許容します。

Rosenberg, et. al.          Standards Track                    [Page 29]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[29ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

7.3.1 Header Field Format

7.3.1 ヘッダーフィールド形式

   Header fields follow the same generic header format as that given in
   Section 2.2 of RFC 2822 [3].  Each header field consists of a field
   name followed by a colon (":") and the field value.

ヘッダーフィールドはRFC2822[3]のセクション2.2におけるそんなに与えられるのと同じジェネリックヘッダー形式に続きます。 各ヘッダーフィールドがコロンがあとに続いたフィールド名から成る、(「:」、)、そして、分野値。

      field-name: field-value

フィールド名: 分野値

   The formal grammar for a message-header specified in Section 25
   allows for an arbitrary amount of whitespace on either side of the
   colon; however, implementations should avoid spaces between the field
   name and the colon and use a single space (SP) between the colon and
   the field-value.

セクション25で指定されたメッセージヘッダーのための形式文法はコロンのどちらかの側の任意の量の空白を考慮します。 しかしながら、実装は、フィールド名とコロンの間の空間を避けて、コロンと分野値の間のシングルスペース(SP)を使用するべきです。

      Subject:            lunch
      Subject      :      lunch
      Subject            :lunch
      Subject: lunch

Subject: 昼食Subject: 昼食Subject:lunch Subject: 昼食

   Thus, the above are all valid and equivalent, but the last is the
   preferred form.

したがって、上記は、すべて有効であって、同等ですが、最終は好まれた形です。

   Header fields can be extended over multiple lines by preceding each
   extra line with at least one SP or horizontal tab (HT).  The line
   break and the whitespace at the beginning of the next line are
   treated as a single SP character.  Thus, the following are
   equivalent:

ヘッダーフィールドは、それぞれの付加的な系列に先行することによって複数の系列の上で広げられるか少なくとも1SPと共に水平タブであるかもしれません(HT)。 次の系列の始めのラインブレイクと空白は単独のSPキャラクタとして扱われます。 したがって、以下は同等です:

      Subject: I know you're there, pick up the phone and talk to me!
      Subject: I know you're there,
               pick up the phone
               and talk to me!

Subject: 私は、あなたがそこにいて、電話をして、私に話すのを知っています! Subject: 私は、あなたがそこにいて、電話をして、私に話すのを知っています!

   The relative order of header fields with different field names is not
   significant.  However, it is RECOMMENDED that header fields which are
   needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
   Max-Forwards, and Proxy-Authorization, for example) appear towards
   the top of the message to facilitate rapid parsing.  The relative
   order of header field rows with the same field name is important.
   Multiple header field rows with the same field-name MAY be present in
   a message if and only if the entire field-value for that header field
   is defined as a comma-separated list (that is, if follows the grammar
   defined in Section 7.3).  It MUST be possible to combine the multiple
   header field rows into one "field-name: field-value" pair, without
   changing the semantics of the message, by appending each subsequent
   field-value to the first, each separated by a comma.  The exceptions
   to this rule are the WWW-Authenticate, Authorization, Proxy-
   Authenticate, and Proxy-Authorization header fields.  Multiple header

異なったフィールド名があるヘッダーフィールドの相対オーダは重要ではありません。 を通してしかしながら、プロキシ処理に必要であるのが、ヘッダーがさばくRECOMMENDEDである、(Route(Record-ルート)がProxy必要である、前方へマックス、およびProxy-承認、例えば)、出現、急速な構文解析を容易にするメッセージの先端に向かって。 同じフィールド名があるヘッダーフィールド行の相対オーダは重要です。 そして、同じフィールド名がある複数のヘッダーフィールド行がメッセージに存在しているかもしれない、そのヘッダーフィールドのための全体の分野値がコンマで切り離されたリストと定義される場合にだけ(すなわち、尾行であるなら、文法は中でセクション7.3を定義しました)。 複数のヘッダーフィールド行を1つに結合するのが可能であるに違いない、「フィールド名:」 それぞれのその後の分野値を1日に追加することによってメッセージの意味論を変えないで、「分野値」組はコンマでそれぞれ分離しました。 この規則への例外がそうである、WWW認証、Authorization、Proxyは認証して、Proxy-承認ヘッダーはさばきます。 複数のヘッダー

Rosenberg, et. al.          Standards Track                    [Page 30]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[30ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   field rows with these names MAY be present in a message, but since
   their grammar does not follow the general form listed in Section 7.3,
   they MUST NOT be combined into a single header field row.

これらの名前がある分野行はメッセージに存在しているかもしれませんが、それらの文法がセクション7.3に記載された一般的な書式に従わないので、ただ一つのヘッダーフィールド行にそれらを結合してはいけません。

   Implementations MUST be able to process multiple header field rows
   with the same name in any combination of the single-value-per-line or
   comma-separated value forms.

実装は1系列あたりのただ一つの値かコンマ区切り値形式のどんな組み合わせでも同じ名前で複数のヘッダーフィールド行を処理できなければなりません。

   The following groups of header field rows are valid and equivalent:

ヘッダーフィールド行の以下のグループは、有効であって、同等です:

      Route: <sip:alice@atlanta.com>
      Subject: Lunch
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

以下を発送してください。 <一口: alice@atlanta.com 、gt;、Subject: 昼食ルート: <一口: bob@biloxi.com 、gt;、ルート: <一口: carol@chicago.com 、gt。

      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Subject: Lunch

以下を発送してください。 <一口: alice@atlanta.com 、gt;、<一口: bob@biloxi.com 、gt;、ルート: <一口: carol@chicago.com 、gt;、Subject: 昼食

      Subject: Lunch
      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
             <sip:carol@chicago.com>

Subject: 昼食ルート: <一口: alice@atlanta.com 、gt;、<一口: bob@biloxi.com 、gt;、<一口: carol@chicago.com 、gt。

   Each of the following blocks is valid but not equivalent to the
   others:

他のものには、それぞれの以下のブロックは、有効ですが、同等ではありません:

      Route: <sip:alice@atlanta.com>
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

以下を発送してください。 <一口: alice@atlanta.com 、gt;、ルート: <一口: bob@biloxi.com 、gt;、ルート: <一口: carol@chicago.com 、gt。

      Route: <sip:bob@biloxi.com>
      Route: <sip:alice@atlanta.com>
      Route: <sip:carol@chicago.com>

以下を発送してください。 <一口: bob@biloxi.com 、gt;、ルート: <一口: alice@atlanta.com 、gt;、ルート: <一口: carol@chicago.com 、gt。

      Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
             <sip:bob@biloxi.com>

以下を発送してください。 <一口: alice@atlanta.com 、gt;、<一口: carol@chicago.com 、gt;、<一口: bob@biloxi.com 、gt。

   The format of a header field-value is defined per header-name.  It
   will always be either an opaque sequence of TEXT-UTF8 octets, or a
   combination of whitespace, tokens, separators, and quoted strings.
   Many existing header fields will adhere to the general form of a
   value followed by a semi-colon separated sequence of parameter-name,
   parameter-value pairs:

ヘッダー分野価値の書式はヘッダー名単位で定義されます。 それは、いつもTEXT-UTF8八重奏の不明瞭な系列か空白、トークン、分離符、および引用文字列の組み合わせのどちらかのようになるでしょう。 多くの既存のヘッダーフィールドがパラメタ名のセミコロンの切り離された系列があとに続いた価値の一般的なフォームを固く守るでしょう、パラメタ価値の組:

         field-name: field-value *(;parameter-name=parameter-value)

フィールド名: 分野価値の*(;パラメタ名がパラメタ値と等しい )

Rosenberg, et. al.          Standards Track                    [Page 31]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[31ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Even though an arbitrary number of parameter pairs may be attached to
   a header field value, any given parameter-name MUST NOT appear more
   than once.

パラメタ組の特殊活字の数字はヘッダーフィールド値に付けられるかもしれませんが、どんな与えられたパラメタ名も一度より多く見えてはいけません。

   When comparing header fields, field names are always case-
   insensitive.  Unless otherwise stated in the definition of a
   particular header field, field values, parameter names, and parameter
   values are case-insensitive.  Tokens are always case-insensitive.
   Unless specified otherwise, values expressed as quoted strings are
   case-sensitive.  For example,

ヘッダーフィールドを比較するとき、フィールド名はいつもケース神経が鈍いです。 別の方法で特定のヘッダーフィールドの定義で述べられない場合、分野値、パラメタ名、およびパラメタ値は大文字と小文字を区別しないです。 トークンはいつも大文字と小文字を区別しないです。 別の方法で指定されない場合、引用文字列として言い表された値は大文字と小文字を区別しています。 例えば

      Contact: <sip:alice@atlanta.com>;expires=3600

接触: <一口: alice@atlanta.com 、gt;、;、=3600を吐き出します。

   is equivalent to

相当

      CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600

接触: <一口: alice@atlanta.com 、gt;、;、=3600を吐き出します。

   and

そして

      Content-Disposition: session;handling=optional

満足している気質: セッション;、取り扱い=任意

   is equivalent to

相当

      content-disposition: Session;HANDLING=OPTIONAL

満足している気質: セッション;、取り扱い=任意

   The following two header fields are not equivalent:

以下の2つのヘッダーフィールドは同等ではありません:

      Warning: 370 devnull "Choose a bigger pipe"
      Warning: 370 devnull "CHOOSE A BIGGER PIPE"

警告: 370 「より大きいパイプを選んでください」というdevnull Warning: 370 devnullは「より大きいパイプを選びます」。

7.3.2 Header Field Classification

7.3.2 ヘッダーフィールド分類

   Some header fields only make sense in requests or responses.  These
   are called request header fields and response header fields,
   respectively.  If a header field appears in a message not matching
   its category (such as a request header field in a response), it MUST
   be ignored.  Section 20 defines the classification of each header
   field.

いくつかのヘッダーフィールドが要求か応答で理解できるだけです。 これらはヘッダーがそれぞれさばく要求ヘッダーフィールドと応答と呼ばれます。 ヘッダーフィールドがカテゴリ(応答における要求ヘッダーフィールドなどの)を合わせないことでメッセージに現れるなら、それを無視しなければなりません。 セクション20はそれぞれのヘッダーフィールドの分類を定義します。

7.3.3 Compact Form

7.3.3 コンパクト形

   SIP provides a mechanism to represent common header field names in an
   abbreviated form.  This may be useful when messages would otherwise
   become too large to be carried on the transport available to it
   (exceeding the maximum transmission unit (MTU) when using UDP, for
   example).  These compact forms are defined in Section 20.  A compact
   form MAY be substituted for the longer form of a header field name at
   any time without changing the semantics of the message.  A header

SIPは、簡略化されたフォームに一般的なヘッダーフィールド名を表すためにメカニズムを提供します。 そうでなければ、メッセージがそれ(UDPを使用するとき例えば、マキシマム・トランスミッション・ユニット(MTU)を超えている)に利用可能な輸送のときに運ぶことができないくらい大きくなるだろうというとき、これは役に立つかもしれません。 これらのコンパクト形はセクション20で定義されます。 メッセージの意味論を変えないで、いつでも、ヘッダーフィールド名の、より長いフォームにコンパクト形を代入するかもしれません。 ヘッダー

Rosenberg, et. al.          Standards Track                    [Page 32]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[32ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   field name MAY appear in both long and short forms within the same
   message.  Implementations MUST accept both the long and short forms
   of each header name.

フィールド名は長いものと同じメッセージの中の同様に短いフォームに載るかもしれません。 実装はそれぞれのヘッダー名の両方の長くて短いフォームを受け入れなければなりません。

7.4 Bodies

7.4 ボディー

   Requests, including new requests defined in extensions to this
   specification, MAY contain message bodies unless otherwise noted.
   The interpretation of the body depends on the request method.

別の方法で注意されない場合、拡大でこの仕様と定義された新しい要求を含む要求はメッセージ本体を含むかもしれません。 ボディーの解釈は要求メソッドによります。

   For response messages, the request method and the response status
   code determine the type and interpretation of any message body.  All
   responses MAY include a body.

応答メッセージのために、要求メソッドと応答ステータスコードはどんなメッセージ本体のタイプと解釈も決定します。 すべての応答がボディーを含むかもしれません。

7.4.1 Message Body Type

7.4.1 メッセージボディータイプ

   The Internet media type of the message body MUST be given by the
   Content-Type header field.  If the body has undergone any encoding
   such as compression, then this MUST be indicated by the Content-
   Encoding header field; otherwise, Content-Encoding MUST be omitted.
   If applicable, the character set of the message body is indicated as
   part of the Content-Type header-field value.

コンテントタイプヘッダーフィールドでメッセージ本体のインターネットメディアタイプを与えなければなりません。 ボディーが圧縮などのように何かコード化を受けたなら、Contentコード化ヘッダーフィールドでこれを示さなければなりません。 さもなければ、Content-コード化を省略しなければなりません。 適切であるなら、メッセージ本体の文字集合はコンテントタイプヘッダーフィールド価値の一部として示されます。

   The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
   the body of the message.  Implementations that send requests
   containing multipart message bodies MUST send a session description
   as a non-multipart message body if the remote implementation requests
   this through an Accept header field that does not contain multipart.

RFC2046[11]で定義された「複合」のMIMEの種類はメッセージ欄の中で使用されるかもしれません。 リモート実装がそれが含まないAcceptヘッダーフィールドを通してこれを要求するなら、複合メッセージ本体を含んでいて、要求を送る実装は非複合のメッセージ本体としてセッション記述を送らなければなりません。複合。

   SIP messages MAY contain binary bodies or body parts. When no
   explicit charset parameter is provided by the sender, media subtypes
   of the "text" type are defined to have a default charset value of
   "UTF-8".

SIPメッセージは2進のボディーか身体の部分を含むかもしれません。 どんな明白なcharsetパラメタも送付者によって提供されないとき、「テキスト」タイプのメディア血液型亜型は、「UTF-8インチ」のデフォルトcharset価値を持つために定義されます。

7.4.2 Message Body Length

7.4.2 メッセージボディーの長さ

   The body length in bytes is provided by the Content-Length header
   field.  Section 20.14 describes the necessary contents of this header
   field in detail.

Content-長さのヘッダーフィールドでバイトで表現されるボディーの長さを提供します。 セクション20.14は詳細にこのヘッダーフィールドの必要なコンテンツについて説明します。

   The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
   (Note: The chunked encoding modifies the body of a message in order
   to transfer it as a series of chunks, each with its own size
   indicator.)

SIPにHTTP/1.1の"chunkedする"の転送コード化を使用してはいけません。 (注意: chunkedコード化は一連の塊としてそれを移すようにメッセージのボディーを変更します、それぞれそれ自身のサイズインディケータで。)

Rosenberg, et. al.          Standards Track                    [Page 33]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[33ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

7.5 Framing SIP Messages

7.5 縁どり一口メッセージ

   Unlike HTTP, SIP implementations can use UDP or other unreliable
   datagram protocols.  Each such datagram carries one request or
   response.  See Section 18 on constraints on usage of unreliable
   transports.

HTTPと異なって、SIP実装はUDPか他の頼り無いデータグラムプロトコルを使用できます。 そのような各データグラムは1つの要求か応答を運びます。 頼り無い輸送の用法でセクション18を規制に見てください。

   Implementations processing SIP messages over stream-oriented
   transports MUST ignore any CRLF appearing before the start-line
   [H4.1].

ストリーム指向の輸送の上にSIPメッセージを処理する実装はスタート系列[H4.1]の前に現れるどんなCRLFも無視しなければなりません。

      The Content-Length header field value is used to locate the end of
      each SIP message in a stream.  It will always be present when SIP
      messages are sent over stream-oriented transports.

Content-長さのヘッダーフィールド価値は、絶え間なくそれぞれのSIPメッセージの終わりの場所を見つけるのに使用されます。 ストリーム指向の輸送の上にSIPメッセージを送るとき、それはいつも存在するでしょう。

8 General User Agent Behavior

8 一般ユーザエージェントの振舞い

   A user agent represents an end system.  It contains a user agent
   client (UAC), which generates requests, and a user agent server
   (UAS), which responds to them.  A UAC is capable of generating a
   request based on some external stimulus (the user clicking a button,
   or a signal on a PSTN line) and processing a response.  A UAS is
   capable of receiving a request and generating a response based on
   user input, external stimulus, the result of a program execution, or
   some other mechanism.

ユーザエージェントはエンドシステムを表します。 それはユーザエージェントクライアント(UAC)を含んでいます。(それは、要求、およびユーザエージェントサーバが(UAS)であると生成します)。(それは、彼らに応じます)。 UACは、何らかの外的刺激(PSTN系列をボタン、または信号をクリックしているユーザ)に基づく要求と処理が応答であると生成することができます。 UASは要求を受け取って、ユーザ入力、外的刺激、プログラム実行の結果、またはある他のメカニズムに基づく応答を生成することができます。

   When a UAC sends a request, the request passes through some number of
   proxy servers, which forward the request towards the UAS. When the
   UAS generates a response, the response is forwarded towards the UAC.

UACが要求を送るとき、要求は何らかの数のプロキシサーバを通り抜けます。(プロキシサーバはUASに向かって要求を転送します)。 UASが応答を生成するとき、UACに向かって応答を送ります。

   UAC and UAS procedures depend strongly on two factors.  First, based
   on whether the request or response is inside or outside of a dialog,
   and second, based on the method of a request.  Dialogs are discussed
   thoroughly in Section 12; they represent a peer-to-peer relationship
   between user agents and are established by specific SIP methods, such
   as INVITE.

UACとUAS手順は強く2つの要素に依存します。 要求か応答が対話、および2番目の中か外にあるかどうか基づく1番目は要求のメソッドを基礎づけました。 セクション12で対話について徹底的に議論します。 それらは、ユーザエージェントの間のピアツーピア関係を表して、INVITEなどの特定のSIPメソッドで設立されます。

   In this section, we discuss the method-independent rules for UAC and
   UAS behavior when processing requests that are outside of a dialog.
   This includes, of course, the requests which themselves establish a
   dialog.

対話の外にある要求を処理するとき、このセクションで、私たちはUACとUASの振舞いのためのメソッドから独立している規則について議論します。 これはもちろん自分たちで対話を確立する要求を含んでいます。

   Security procedures for requests and responses outside of a dialog
   are described in Section 26.  Specifically, mechanisms exist for the
   UAS and UAC to mutually authenticate.  A limited set of privacy
   features are also supported through encryption of bodies using
   S/MIME.

対話における外の要求と応答のためのセキュリティ手順はセクション26で説明されます。 明確に、メカニズムは存在しています。UASとUACが互いに認証するように。 また、限られたセットのプライバシー機能は、S/MIMEを使用しながら、ボディーの暗号化でサポートされます。

Rosenberg, et. al.          Standards Track                    [Page 34]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[34ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

8.1 UAC Behavior

8.1 UACの振舞い

   This section covers UAC behavior outside of a dialog.

このセクションはUACの振舞いを対話の外にカバーします。

8.1.1 Generating the Request

8.1.1 要求を生成すること。

   A valid SIP request formulated by a UAC MUST, at a minimum, contain
   the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
   and Via; all of these header fields are mandatory in all SIP
   requests.  These six header fields are the fundamental building
   blocks of a SIP message, as they jointly provide for most of the
   critical message routing services including the addressing of
   messages, the routing of responses, limiting message propagation,
   ordering of messages, and the unique identification of transactions.
   These header fields are in addition to the mandatory request line,
   which contains the method, Request-URI, and SIP version.

有効なSIP要求が最小限でUAC MUSTによって定式化されて、以下のヘッダーフィールドを含んでください: を通してそして、CSeq、呼び出しID、前方へマックス、。 これらのヘッダーフィールドのすべてがすべてのSIP要求で義務的です。 これらの6つのヘッダーフィールドがSIPメッセージの基本的なブロックです、共同でメッセージのアドレシングを含む重要なメッセージルーティングサービスの大部分に備えるとき、応答のルーティング、メッセージ伝播を制限して、メッセージ、およびトランザクションのユニークな識別を注文して。 これらのヘッダーフィールドは義務的な要求系列に加えています。系列はメソッド、Request-URI、およびSIPバージョンを含みます。

   Examples of requests sent outside of a dialog include an INVITE to
   establish a session (Section 13) and an OPTIONS to query for
   capabilities (Section 11).

対話の外に送られた要求に関する例は、能力のために(セクション11)について質問するためにセッション(セクション13)とOPTIONSを証明するためにINVITEを含んでいます。

8.1.1.1 Request-URI

8.1.1.1 要求URI

   The initial Request-URI of the message SHOULD be set to the value of
   the URI in the To field.  One notable exception is the REGISTER
   method; behavior for setting the Request-URI of REGISTER is given in
   Section 10.  It may also be undesirable for privacy reasons or
   convenience to set these fields to the same value (especially if the
   originating UA expects that the Request-URI will be changed during
   transit).

初期のRequest-URI、メッセージSHOULDでは、中のToがさばくURIの値に設定されてください。 1つの注目に値する例外がREGISTERメソッドです。 セクション10でREGISTERのRequest-URIを設定するための振舞いを与えます。 また、プライバシー理由か便利が同じ値にこれらの分野を設定するのも、望ましくないかもしれません(特に起因しているUAが、Request-URIがトランジットの間変えられると予想するなら)。

   In some special circumstances, the presence of a pre-existing route
   set can affect the Request-URI of the message.  A pre-existing route
   set is an ordered set of URIs that identify a chain of servers, to
   which a UAC will send outgoing requests that are outside of a dialog.
   Commonly, they are configured on the UA by a user or service provider
   manually, or through some other non-SIP mechanism.  When a provider
   wishes to configure a UA with an outbound proxy, it is RECOMMENDED
   that this be done by providing it with a pre-existing route set with
   a single URI, that of the outbound proxy.

いくつかの特殊事情では、先在のルートセットの存在はメッセージのRequest-URIに影響できます。 先在のルートセットはUACが対話の外にある送信する要求を送るサーバのチェーンを特定する1つの順序集合のURIです。 一般的に、それらは手動かある他の非SIPメカニズムを通してUAでユーザかサービスプロバイダーによって構成されます。 プロバイダーが外国行きのプロキシでUAを構成したがっているとき、ただ一つのURIで設定された、先在のルート、外国行きのプロキシのものをそれに提供することによってこれをするのは、RECOMMENDEDです。

   When a pre-existing route set is present, the procedures for
   populating the Request-URI and Route header field detailed in Section
   12.2.1.1 MUST be followed (even though there is no dialog), using the
   desired Request-URI as the remote target URI.

先在のルートセットが存在しているとき、Request-URIとRouteヘッダーフィールドに居住すると.1がセクション12.2.1で詳しく述べられたので、手順に従わなければなりません(対話が全くありませんが)、リモート目標URIとして必要なRequest-URIを使用して。

Rosenberg, et. al.          Standards Track                    [Page 35]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[35ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

8.1.1.2 To

8.1.1.2

   The To header field first and foremost specifies the desired
   "logical" recipient of the request, or the address-of-record of the
   user or resource that is the target of this request.  This may or may
   not be the ultimate recipient of the request.  The To header field
   MAY contain a SIP or SIPS URI, but it may also make use of other URI
   schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.
   All SIP implementations MUST support the SIP URI scheme.  Any
   implementation that supports TLS MUST support the SIPS URI scheme.
   The To header field allows for a display name.

ヘッダーがまず第一にさばくToは要求の必要な「論理的な」受取人、またはこの要求の目標であるユーザかリソースの記録されている住所を指定します。 これは要求の究極の受取人であるかもしれません。 ToヘッダーフィールドがSIPかSIPS URIを含むかもしれませんが、また、他のURI体系を利用するかもしれない、(適切であるときに、URL(例えば、RFC2806[9]))をtelします。 すべてのSIP実装がSIP URI体系をサポートしなければなりません。 TLS MUSTサポートがSIPS URI体系であるとサポートするどんな実装。 Toヘッダーフィールドはディスプレイ名を考慮します。

   A UAC may learn how to populate the To header field for a particular
   request in a number of ways.  Usually the user will suggest the To
   header field through a human interface, perhaps inputting the URI
   manually or selecting it from some sort of address book.  Frequently,
   the user will not enter a complete URI, but rather a string of digits
   or letters (for example, "bob").  It is at the discretion of the UA
   to choose how to interpret this input.  Using the string to form the
   user part of a SIP URI implies that the UA wishes the name to be
   resolved in the domain to the right-hand side (RHS) of the at-sign in
   the SIP URI (for instance, sip:bob@example.com).  Using the string to
   form the user part of a SIPS URI implies that the UA wishes to
   communicate securely, and that the name is to be resolved in the
   domain to the RHS of the at-sign.  The RHS will frequently be the
   home domain of the requestor, which allows for the home domain to
   process the outgoing request.  This is useful for features like
   "speed dial" that require interpretation of the user part in the home
   domain.  The tel URL may be used when the UA does not wish to specify
   the domain that should interpret a telephone number that has been
   input by the user.  Rather, each domain through which the request
   passes would be given that opportunity.  As an example, a user in an
   airport might log in and send requests through an outbound proxy in
   the airport.  If they enter "411" (this is the phone number for local
   directory assistance in the United States), that needs to be
   interpreted and processed by the outbound proxy in the airport, not
   the user's home domain.  In this case, tel:411 would be the right
   choice.

UACは多くの方法で特定の要求のためのToヘッダーフィールドに居住する方法を学ぶかもしれません。 通常、ユーザはヒューマンインターフェースを通してヘッダーフィールドに提案するでしょう、恐らく手動でURIを入力するか、またはある種のアドレス帳からそれを選択して。 頻繁に、ユーザは完全なURIに入るのではなく、むしろ一連のケタか手紙に入るでしょう(例えば、「たたいてください」)。 この入力を解釈する方法を選ぶために、UAの裁量にはそれがあります。 SIP URIの一部が含意するユーザを形成する名前をそのドメインでUAによって右手に決議されたがっているストリングを使用して、サインインのときにSIP URI(例えば、一口: bob@example.com )に面があってください(RHS)。 UAはしっかりと交信したがっています、そして、名前はそのドメインでSIPS URIのユーザ部分を形成するのにストリングを使用することによってサインのRHSに決議されるつもりであることです。 RHSは頻繁に要請者のホームドメインになるでしょう。(その要請者は、ホームドメインが送信する要求を処理するのを許容します)。 これは「短縮ダイヤル」のようなホームドメインのユーザ部分の解釈を必要とする特徴の役に立ちます。 UAがユーザによって入力された電話番号を解釈するべきであるドメインを指定したがっていないとき、tel URLは使用されるかもしれません。 むしろ、要求に合格する各ドメインにその機会を与えるでしょう。 例として、空港のユーザは、空港の外国行きのプロキシを通して要求にログインして、送るかもしれません。 彼らが「411」に入るなら(これは合衆国でのローカルディレクトリ支援のための電話番号です)、それは、ユーザのホームドメインではなく、空港の外国行きのプロキシによって解釈されて、処理される必要があります。 この場合、tel:411は正しい選択でしょう。

   A request outside of a dialog MUST NOT contain a To tag; the tag in
   the To field of a request identifies the peer of the dialog.  Since
   no dialog is established, no tag is present.

対話の外部がToタグを含んではいけないという要求。 要求のTo分野のタグは対話の同輩を特定します。 対話が全く確立されないので、どんなタグも存在していません。

   For further information on the To header field, see Section 20.39.
   The following is an example of a valid To header field:

Toヘッダーフィールドの詳細に関しては、セクション20.39を見てください。 ↓これは有効なToヘッダーフィールドに関する例です:

      To: Carol <sip:carol@chicago.com>

To: キャロル<一口: carol@chicago.com 、gt。

Rosenberg, et. al.          Standards Track                    [Page 36]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[36ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

8.1.1.3 From

8.1.1.3

   The From header field indicates the logical identity of the initiator
   of the request, possibly the user's address-of-record.  Like the To
   header field, it contains a URI and optionally a display name.  It is
   used by SIP elements to determine which processing rules to apply to
   a request (for example, automatic call rejection).  As such, it is
   very important that the From URI not contain IP addresses or the FQDN
   of the host on which the UA is running, since these are not logical
   names.

Fromヘッダーフィールドは要求の創始者の論理的なアイデンティティ、ことによるとユーザの記録されている住所を示します。 Toヘッダーフィールドのように、URIを含んでいます、そして、任意に、aは名前を表示します。 それはSIP要素によって使用されて、要求(例えば、自動呼び出し拒絶)に適用するためにどの処理規則を決定するか。 そういうものとして、From URIがUAが稼働する予定であるホストのIPアドレスかFQDNを含まないのは、非常に重要です、これらが論理的な名前でないので。

   The From header field allows for a display name.  A UAC SHOULD use
   the display name "Anonymous", along with a syntactically correct, but
   otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
   identity of the client is to remain hidden.

Fromヘッダーフィールドはディスプレイ名を考慮します。 UAC SHOULDは「匿名」というディスプレイ名を使用します、シンタクス上正しい、しかし、そうでなければ、無意味なURI(一口: thisis@anonymous.invalid のような)と共に、クライアントのアイデンティティが隠されたままで残るつもりであるなら。

   Usually, the value that populates the From header field in requests
   generated by a particular UA is pre-provisioned by the user or by the
   administrators of the user's local domain.  If a particular UA is
   used by multiple users, it might have switchable profiles that
   include a URI corresponding to the identity of the profiled user.
   Recipients of requests can authenticate the originator of a request
   in order to ascertain that they are who their From header field
   claims they are (see Section 22 for more on authentication).

通常、特定のUAによって生成された要求におけるFromヘッダーフィールドに居住する値はユーザかユーザの局所領域の管理者によってあらかじめ食糧を供給されます。 特定のUAが複数のユーザによって使用されるなら、それは輪郭を描かれたユーザのアイデンティティに対応するURIを含んでいるスイッチできるプロフィールを持っているかもしれません。 要求の受取人は、彼らがそれらのFromヘッダーフィールドによる主張彼らが人であることを確かめるために要求の創始者を認証できます(詳しい情報については、セクション22を認証に見てください)。

   The From field MUST contain a new "tag" parameter, chosen by the UAC.
   See Section 19.3 for details on choosing a tag.

From分野はUACによって選ばれた新しい「タグ」パラメタを含まなければなりません。 タグを選ぶことに関する詳細に関してセクション19.3を見てください。

   For further information on the From header field, see Section 20.20.
   Examples:

Fromヘッダーフィールドの詳細に関しては、セクション20.20を見てください。 例:

      From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
      From: sip:+12125551212@phone2net.com;tag=887s
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

From: 「ボブ」<一口: bob@biloxi.com 、gt;、;=a48s From:にタグ付けをしてください 一口: 887+ 12125551212@phone2net.com;tag =From: 匿名の<一口: c8oqz84zk7z@privacy.org 、gt;、;=hyh8にタグ付けをしてください

8.1.1.4 Call-ID

8.1.1.4 呼び出しID

   The Call-ID header field acts as a unique identifier to group
   together a series of messages.  It MUST be the same for all requests
   and responses sent by either UA in a dialog.  It SHOULD be the same
   in each registration from a UA.

Call-IDヘッダーフィールドは、一連のメッセージを一緒に分類するためにユニークな識別子として機能します。 対話でUAによって送られたすべての要求と応答に、それは同じであるに違いありません。 それ、SHOULD、各登録では、UAから、同じであってください。

   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA.  Note that when requests are retried after certain

UACによって作成された新しい要求では、メソッド特異的行動でくつがえされない場合、どんな対話の外ではも、Call-IDヘッダーフィールドがスペースと時間、グローバルにユニークな識別子としてUACによって選定されなければなりません。 すべてのSIP UAsには、それらが生産するCall IDヘッダーフィールドがいかなる他のUAによってもうっかり生成されないのを保証する手段がなければなりません。 確かであった後に要求が再試行されたらそれに注意してください。

Rosenberg, et. al.          Standards Track                    [Page 37]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[37ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   failure responses that solicit an amendment to a request (for
   example, a challenge for authentication), these retried requests are
   not considered new requests, and therefore do not need new Call-ID
   header fields; see Section 8.1.3.5.

要求(例えば、認証のための挑戦)の修正に請求する失敗応答、これらの再試行された要求は新しい要求であることは考えられないで、またしたがって、新しいCall-IDヘッダーフィールドを必要としません。 .5にセクション8.1.3を見てください。

   Use of cryptographically random identifiers (RFC 1750 [12]) in the
   generation of Call-IDs is RECOMMENDED.  Implementations MAY use the
   form "localid@host".  Call-IDs are case-sensitive and are simply
   compared byte-by-byte.

使用、暗号で、無作為の識別子、(Call-IDの世代におけるRFC1750[12])はRECOMMENDEDです。 実装はフォーム" localid@host "を使用するかもしれません。 呼び出しIDは、大文字と小文字を区別していて、バイトごとに単に比較されます。

      Using cryptographically random identifiers provides some
      protection against session hijacking and reduces the likelihood of
      unintentional Call-ID collisions.

暗号で無作為の識別子を使用するのは、セッションハイジャックに対する何らかの保護を提供して、意図的でないCall-ID衝突の見込みを減少させます。

   No provisioning or human interface is required for the selection of
   the Call-ID header field value for a request.

どんな食糧を供給するのもヒューマンインターフェースも要求のためのCall-IDヘッダーフィールド価値の選択に必要ではありません。

   For further information on the Call-ID header field, see Section
   20.8.

Call-IDヘッダーフィールドの詳細に関しては、セクション20.8を見てください。

   Example:

例:

      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

呼び出しID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

8.1.1.5 CSeq

8.1.1.5 CSeq

   The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

CSeqヘッダーフィールドはトランザクションを特定して、命令する方法として機能します。 それは一連番号とメソッドから成ります。 メソッドは要求のものに合わなければなりません。 非REGISTER要求において、対話の外では、一連番号値が任意です。 一連番号値は、32ビットの符号のない整数として表現できなければならなくて、2**31以下でなければなりません。 上記のガイドライン、クライアントがどんなメカニズムも使用するかもしれないということになる限り、それはCSeqヘッダーフィールド値を選択したがっています。

   Section 12.2.1.1 discusses construction of the CSeq for requests
   within a dialog.

セクション12.2 .1 .1 要求のために対話の中でCSeqの構造について議論します。

   Example:

例:

      CSeq: 4711 INVITE

CSeq: 4711年の招待

Rosenberg, et. al.          Standards Track                    [Page 38]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[38ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

8.1.1.6 Max-Forwards

8.1.1.6 前方へマックス

   The Max-Forwards header field serves to limit the number of hops a
   request can transit on the way to its destination.  It consists of an
   integer that is decremented by one at each hop.  If the Max-Forwards
   value reaches 0 before the request reaches its destination, it will
   be rejected with a 483(Too Many Hops) error response.

前方へマックスヘッダーフィールドは、目的地への途中で要求が通過できるホップの数を制限するのに役立ちます。 それは各ホップの1つ減少する整数から成ります。 また、要求が目的地に到着する前に前方へマックス値が0に達すると、それが483で拒絶される、(Manyホップス) 誤り応答。

   A UAC MUST insert a Max-Forwards header field into each request it
   originates with a value that SHOULD be 70.  This number was chosen to
   be sufficiently large to guarantee that a request would not be
   dropped in any SIP network when there were no loops, but not so large
   as to consume proxy resources when a loop does occur.  Lower values
   should be used with caution and only in networks where topologies are
   known by the UA.

UAC MUSTはSHOULDが70歳であるというそれが値で溯源する各要求に前方へマックスヘッダーフィールドを挿入します。 輪がないのにもかかわらず、輪が現れるとプロキシリソースを消費するくらいには大きくない状態であったとき、この数は、要求がどんなSIPネットワークでも下げられないのを保証できるくらい大きくなるように選ばれました。 下側の値はtopologiesがUAによって知られているネットワークだけに使用されるべきです。

8.1.1.7 Via

を通して8.1.1.7。

   The Via header field indicates the transport used for the transaction
   and identifies the location where the response is to be sent.  A Via
   header field value is added only after the transport that will be
   used to reach the next hop has been selected (which may involve the
   usage of the procedures in [4]).

Viaヘッダーフィールドは、トランザクションに使用される輸送を示して、送られる応答がことである位置を特定します。 次のホップに達するのに使用される輸送が選択された後にだけViaヘッダーフィールド価値は高められます。(手順の用法に[4])にかかわるかもしれない。

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

UACが要求を作成するとき、それはその要求にViaを挿入しなければなりません。 ヘッダーフィールドにおけるプロトコル名とプロトコルバージョンは、それぞれSIPと2.0であるに違いありません。 Viaヘッダーフィールド価値はブランチパラメタを含まなければなりません。 このパラメタは、その要求で作成されたトランザクションを特定するのに使用されます。 このパラメタはクライアントとサーバの両方によって使用されます。

   The branch parameter value MUST be unique across space and time for
   all requests sent by the UA.  The exceptions to this rule are CANCEL
   and ACK for non-2xx responses.  As discussed below, a CANCEL request
   will have the same value of the branch parameter as the request it
   cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx
   response will also have the same branch ID as the INVITE whose
   response it acknowledges.

ブランチパラメタ価値はUAによって送られたすべての要求のためのスペースと時間の向こう側にユニークであるに違いありません。 この規則への例外はキャンセルであり、非2xxのためのACKは応答です。 以下で議論するように、キャンセル要求にはそれが中止する要求としてのブランチパラメタの同じ値があるでしょう。 また、セクション17.1.1で議論するように、.3、非2xx応答のためのACKにはそれが応答を承諾するINVITEと同じブランチIDがあるでしょう。

      The uniqueness property of the branch ID parameter, to facilitate
      its use as a transaction ID, was not part of RFC 2543.

ユニークさの特性、RFCの一部が、トランザクションIDとして使用を容易にするためには、2543のブランチIDパラメタではありませんでした。

   The branch ID inserted by an element compliant with this
   specification MUST always begin with the characters "z9hG4bK".  These
   7 characters are used as a magic cookie (7 is deemed sufficient to
   ensure that an older RFC 2543 implementation would not pick such a
   value), so that servers receiving the request can determine that the
   branch ID was constructed in the fashion described by this

この仕様による対応することの要素に従ってIDが挿入したブランチはキャラクタ"z9hG4bK"と共にいつも始まらなければなりません。 これらの7つのキャラクタが魔法のクッキーとして使用されます(7は2543年の、より古いRFC実装がそのような値を選ばないのを保証するために十分であると考えられます)、要求を受け取るサーバが、ブランチIDがこれによって説明されたファッションで構成されたことを決定できるように

Rosenberg, et. al.          Standards Track                    [Page 39]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[39ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   specification (that is, globally unique).  Beyond this requirement,
   the precise format of the branch token is implementation-defined.

仕様、(そうするグローバルにユニークである、) この要件を超えて、ブランチトークンの正確な形式は実装で定義されています。

   The Via header maddr, ttl, and sent-by components will be set when
   the request is processed by the transport layer (Section 18).

Viaヘッダーはmaddrします、ttl、そして、トランスポート層(セクション18)によって要求が処理されるとき、送って、コンポーネントが設定されるでしょう。

   Via processing for proxies is described in Section 16.6 Item 8 and
   Section 16.7 Item 3.

プロキシのための処理で、セクション16.6 Item8とセクション16.7 Item3で説明されます。

8.1.1.8 Contact

8.1.1.8 接触

   The Contact header field provides a SIP or SIPS URI that can be used
   to contact that specific instance of the UA for subsequent requests.
   The Contact header field MUST be present and contain exactly one SIP
   or SIPS URI in any request that can result in the establishment of a
   dialog.  For the methods defined in this specification, that includes
   only the INVITE request.  For these requests, the scope of the
   Contact is global.  That is, the Contact header field value contains
   the URI at which the UA would like to receive requests, and this URI
   MUST be valid even if used in subsequent requests outside of any
   dialogs.

Contactヘッダーフィールドはその後の要求のためにUAのその特定のインスタンスに連絡するのに使用できるSIPかSIPS URIを提供します。 Contactヘッダーフィールドは、存在していて、対話の確立をもたらすことができるどんな要求にもちょうど1SIPかSIPS URIを含まなければなりません。 この仕様に基づき定義されたメソッドのために、それはINVITE要求だけを含んでいます。 これらの要求において、Contactの範囲はグローバルです。 すなわち、Contactヘッダーフィールド価値はUAが要求を受け取りたがっているURIを含んでいます、そして、外のその後の要求で使用されても、このURIはどんな対話でも有効であるに違いありません。

   If the Request-URI or top Route header field value contains a SIPS
   URI, the Contact header field MUST contain a SIPS URI as well.

Request-URIか最高Routeヘッダーフィールド価値がSIPS URIを含んでいるなら、Contactヘッダーフィールドはまた、SIPS URIを含まなければなりません。

   For further information on the Contact header field, see Section
   20.10.

Contactヘッダーフィールドの詳細に関しては、セクション20.10を見てください。

8.1.1.9 Supported and Require

8.1.1.9、サポートして、必要

   If the UAC supports extensions to SIP that can be applied by the
   server to the response, the UAC SHOULD include a Supported header
   field in the request listing the option tags (Section 19.2) for those
   extensions.

UACがサーバで応答に適用できるSIPに拡大をサポートするなら、UAC SHOULDはそれらの拡大のためのオプションタグ(セクション19.2)を記載する要求にSupportedヘッダーフィールドを含んでいます。

   The option tags listed MUST only refer to extensions defined in
   standards-track RFCs.  This is to prevent servers from insisting that
   clients implement non-standard, vendor-defined features in order to
   receive service.  Extensions defined by experimental and
   informational RFCs are explicitly excluded from usage with the
   Supported header field in a request, since they too are often used to
   document vendor-defined extensions.

タグが記載したオプションは標準化過程RFCsで定義された拡大について言及するだけでよいです。 これは、サーバが、クライアントがサービスを受けるために標準的でなくて、ベンダーによって定義された特徴を実装すると主張するのを防ぐためのものです。 実験的で情報のRFCsによって定義された拡大は要求におけるSupportedヘッダーフィールドで用法から明らかに除かれます、彼らもベンダーによって定義された拡大を記録するのにしばしば使用されるので。

   If the UAC wishes to insist that a UAS understand an extension that
   the UAC will apply to the request in order to process the request, it
   MUST insert a Require header field into the request listing the
   option tag for that extension.  If the UAC wishes to apply an
   extension to the request and insist that any proxies that are

UACが、UASがUACが要求を処理するために要求に適用する拡大を理解していると主張したいなら、それはその拡大のためのオプションタグを記載する要求にRequireヘッダーフィールドを挿入しなければなりません。 UACが拡大を要求に適用して、主張したがっている、それ、どんなプロキシ

Rosenberg, et. al.          Standards Track                    [Page 40]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[40ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   traversed understand that extension, it MUST insert a Proxy-Require
   header field into the request listing the option tag for that
   extension.

横断されて、その拡大を理解してください、そして、それはaを挿入しなければなりません。その拡大のためのオプションタグを記載して、要求へのヘッダーフィールドをProxy必要としてください。

   As with the Supported header field, the option tags in the Require
   and Proxy-Require header fields MUST only refer to extensions defined
   in standards-track RFCs.

Supportedヘッダーフィールドのように、オプションは、標準化過程RFCsで拡大と定義されて、分野が参照するだけでよいヘッダーにRequireでタグ付けをして、Proxy必要とします。

8.1.1.10 Additional Message Components

8.1.1.10 追加メッセージコンポーネント

   After a new request has been created, and the header fields described
   above have been properly constructed, any additional optional header
   fields are added, as are any header fields specific to the method.

新しい要求を作成してあって、適切に構成された後に、どんな追加任意のヘッダーフィールドも加えられます、メソッドに特定のどんなヘッダーフィールドのようにも。

   SIP requests MAY contain a MIME-encoded message-body.  Regardless of
   the type of body that a request contains, certain header fields must
   be formulated to characterize the contents of the body.  For further
   information on these header fields, see Sections 20.11 through 20.15.

SIP要求はMIMEでコード化されたメッセージ本体を含むかもしれません。 要求が含むボディーのタイプにかかわらず、ボディーのコンテンツを特徴付けるためにあるヘッダーフィールドを定式化しなければなりません。 これらのヘッダーフィールドの詳細に関しては、セクション20.11〜20.15を見てください。

8.1.2 Sending the Request

8.1.2 要求を送ること。

   The destination for the request is then computed.  Unless there is
   local policy specifying otherwise, the destination MUST be determined
   by applying the DNS procedures described in [4] as follows.  If the
   first element in the route set indicated a strict router (resulting
   in forming the request as described in Section 12.2.1.1), the
   procedures MUST be applied to the Request-URI of the request.
   Otherwise, the procedures are applied to the first Route header field
   value in the request (if one exists), or to the request's Request-URI
   if there is no Route header field present.  These procedures yield an
   ordered set of address, port, and transports to attempt.  Independent
   of which URI is used as input to the procedures of [4], if the
   Request-URI specifies a SIPS resource, the UAC MUST follow the
   procedures of [4] as if the input URI were a SIPS URI.

そして、要求のための目的地は計算されます。 別の方法で指定するローカルの方針がない場合、以下の[4]で説明されたDNS手順を適用することによって、目的地を決定しなければなりません。 ルートセットにおける最初の要素が厳しいルータ(セクション12.2.1で.1について説明するので要求を形成するようになる)を示したなら、要求のRequest-URIに手順を適用しなければなりません。 さもなければ、手順はどんな存在しているRouteヘッダーフィールドもなければヘッダーフィールドが要求(1つが存在しているなら)か、要求のRequest-URIに評価する最初のRouteに適用されます。 これらの手順は試みる1つの順序集合のアドレス、ポート、および輸送をもたらします。 Request-URIがSIPSリソースを指定するならどのURIが[4]の手順に入力されるように使用されるかから独立しています、UAC MUSTはまるで入力URIがSIPS URIであるかのように[4]の手順に従います。

   Local policy MAY specify an alternate set of destinations to attempt.
   If the Request-URI contains a SIPS URI, any alternate destinations
   MUST be contacted with TLS.  Beyond that, there are no restrictions
   on the alternate destinations if the request contains no Route header
   field.  This provides a simple alternative to a pre-existing route
   set as a way to specify an outbound proxy.  However, that approach
   for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
   route set with a single URI SHOULD be used instead.  If the request
   contains a Route header field, the request SHOULD be sent to the
   locations derived from its topmost value, but MAY be sent to any
   server that the UA is certain will honor the Route and Request-URI
   policies specified in this document (as opposed to those in RFC
   2543).  In particular, a UAC configured with an outbound proxy SHOULD

ローカルの方針は試みる代替のセットの目的地を指定するかもしれません。 Request-URIがSIPS URIを含んでいるなら、TLSと共にどんな代替の目的地にも接触しなければなりません。 それを超えて、要求がRouteヘッダーフィールドを全く含んでいないなら、制限が全く代替の目的地にありません。 これは外国行きのプロキシを指定する方法として先在のルートセットへの簡単な代替手段を提供します。 しかしながら、外国行きのプロキシを構成するためのそのアプローチはNOT RECOMMENDEDです。 独身のURI SHOULDが代わりに使用されている状態で、先在のルートはセットしました。 要求がRouteヘッダーフィールドを含んでいるなら、要求SHOULDを最上の値から得られた位置に送りましたが、尊敬するUAがRouteを確信しているどんなサーバにも送ったかもしれません、そして、Request-URI方針は本書では(RFC2543のそれらと対照的に)指定しました。 特に、UACは外国行きのプロキシでSHOULDを構成しました。

Rosenberg, et. al.          Standards Track                    [Page 41]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[41ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   attempt to send the request to the location indicated in the first
   Route header field value instead of adopting the policy of sending
   all messages to the outbound proxy.

すべてのメッセージを外国行きのプロキシに送る方針を採ることの代わりに最初のRouteヘッダーフィールド価値で示された位置に要求を送るのを試みてください。

      This ensures that outbound proxies that do not add Record-Route
      header field values will drop out of the path of subsequent
      requests.  It allows endpoints that cannot resolve the first Route
      URI to delegate that task to an outbound proxy.

これは、Record-ルートヘッダーフィールド値を加えない外国行きのプロキシがその後の要求の経路を脱落するのを確実にします。 それで、最初のRoute URIを決議できない終点はそのタスクを外国行きのプロキシへ代表として派遣することができます。

   The UAC SHOULD follow the procedures defined in [4] for stateful
   elements, trying each address until a server is contacted.  Each try
   constitutes a new transaction, and therefore each carries a different
   topmost Via header field value with a new branch parameter.
   Furthermore, the transport value in the Via header field is set to
   whatever transport was determined for the target server.

UAC SHOULDはサーバが連絡されるまで各アドレスを試みて、stateful要素のための[4]で定義された手順に従います。 各トライは新しいトランザクションを構成します、そして、したがって、それぞれが新しいブランチパラメタで異なった最上のViaヘッダーフィールド価値を運びます。 その上、Viaヘッダーフィールドにおける輸送値は目標サーバのために決定したどんな輸送にも設定されます。

8.1.3 Processing Responses

8.1.3 処理応答

   Responses are first processed by the transport layer and then passed
   up to the transaction layer.  The transaction layer performs its
   processing and then passes the response up to the TU.  The majority
   of response processing in the TU is method specific.  However, there
   are some general behaviors independent of the method.

応答は、最初に、トランスポート層によって処理されて、次に、トランザクション層まで通過されます。 トランザクション層は、TUまで処理を実行して、次に、応答を通過します。 TUの応答処理の大多数はメソッド特有です。 しかしながら、メソッドの如何にかかわらずいくつかの一般的な振舞いがあります。

8.1.3.1 Transaction Layer Errors

8.1.3.1 トランザクション層の誤り

   In some cases, the response returned by the transaction layer will
   not be a SIP message, but rather a transaction layer error.  When a
   timeout error is received from the transaction layer, it MUST be
   treated as if a 408 (Request Timeout) status code has been received.
   If a fatal transport error is reported by the transport layer
   (generally, due to fatal ICMP errors in UDP or connection failures in
   TCP), the condition MUST be treated as a 503 (Service Unavailable)
   status code.

いくつかの場合、トランザクション層で返された応答はSIPメッセージではなく、むしろトランザクション層の誤りになるでしょう。 トランザクション層からタイムアウト誤りを受けるとき、まるで408(Timeoutを要求する)ステータスコードを受け取ったかのようにそれを扱わなければなりません。 致命的な輸送誤りがトランスポート層(一般にUDPの致命的なICMP誤りかTCPでの接続失敗への支払われるべきもの)のそばで報告されるなら、503(サービスUnavailable)ステータスコードとして状態を扱わなければなりません。

8.1.3.2 Unrecognized Responses

8.1.3.2 認識されていない応答

   A UAC MUST treat any final response it does not recognize as being
   equivalent to the x00 response code of that class, and MUST be able
   to process the x00 response code for all classes.  For example, if a
   UAC receives an unrecognized response code of 431, it can safely
   assume that there was something wrong with its request and treat the
   response as if it had received a 400 (Bad Request) response code.  A
   UAC MUST treat any provisional response different than 100 that it
   does not recognize as 183 (Session Progress).  A UAC MUST be able to
   process 100 and 183 responses.

UAC MUSTは扱います。それがするどんな最終的な応答も、すべてのクラスにおいてそのクラスのx00応答コードに同等であるとして認識して、x00応答コードを処理するはずがないことができます。 例えば、UACが431の認識されていない応答コードを受け取るなら、それは、まるで400(悪いRequest)応答コードを受け取ったかのように要求には不具合があったと安全に仮定して、応答を扱うことができます。 それがする100と異なったどんな暫定的な応答も183(セッションProgress)として認識しないUAC MUSTの御馳走。 UAC MUST、100と183の応答を処理できてください。

Rosenberg, et. al.          Standards Track                    [Page 42]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[42ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

8.1.3.3 Vias

8.1.3.3 Vias

   If more than one Via header field value is present in a response, the
   UAC SHOULD discard the message.

1つ以上のViaヘッダーフィールド価値が応答で存在しているなら、UAC SHOULDはメッセージを捨てます。

      The presence of additional Via header field values that precede
      the originator of the request suggests that the message was
      misrouted or possibly corrupted.

要求の創始者の上位である追加Viaヘッダーフィールド値の存在は、メッセージがmisroutedされたか、またはことによると崩壊したと示唆します。

8.1.3.4 Processing 3xx Responses

8.1.3.4 処理3xx応答

   Upon receipt of a redirection response (for example, a 301 response
   status code), clients SHOULD use the URI(s) in the Contact header
   field to formulate one or more new requests based on the redirected
   request.  This process is similar to that of a proxy recursing on a
   3xx class response as detailed in Sections 16.5 and 16.6.  A client
   starts with an initial target set containing exactly one URI, the
   Request-URI of the original request.  If a client wishes to formulate
   new requests based on a 3xx class response to that request, it places
   the URIs to try into the target set.  Subject to the restrictions in
   this specification, a client can choose which Contact URIs it places
   into the target set.  As with proxy recursion, a client processing
   3xx class responses MUST NOT add any given URI to the target set more
   than once.  If the original request had a SIPS URI in the Request-
   URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD
   inform the user of the redirection to an insecure URI.

リダイレクション応答(例えば、301応答ステータスコード)を受け取り次第、クライアントSHOULDは、向け直された要求に基づく1つ以上の新しい要求を定式化するのにContactヘッダーフィールドにURIを使用します。 このプロセスは3xxクラス応答のときにセクション16.5と16.6で詳しく述べられるように「再-呪」うプロキシのものと同様です。 クライアントはまさに1つのURIを含むように設定された、初期の目標、オリジナルの要求のRequest-URIから始まります。 クライアントがその要求への3xxクラス応答に基づく新しい要求を定式化したいなら、それは、目標セットに試みるためにURIを置きます。 この仕様に基づく制限を条件として、クライアントは、それが目標に置くどのContact URIがセットしたかを選ぶことができます。 プロキシ再帰なら、3xxクラス応答を処理するクライアントは一度より多くの目標セットにどんな与えられたURIも追加してはいけません。 オリジナルの要求がRequest URIでSIPS URIを持っていたなら、クライアントは非SIPS URIへの「再-呪い」に選ぶかもしれませんが、SHOULDは不安定なURIへのリダイレクションについてユーザに知らせます。

      Any new request may receive 3xx responses themselves containing
      the original URI as a contact.  Two locations can be configured to
      redirect to each other.  Placing any given URI in the target set
      only once prevents infinite redirection loops.

接触としてオリジナルのURIを含んでいて、どんな新しい要求も3xx応答自体を受けるかもしれません。 2つの位置が、互いに向け直すために構成できます。 一度だけどんな与えられたURIも目標セットに置くと、無限のリダイレクション輪は防がれます。

   As the target set grows, the client MAY generate new requests to the
   URIs in any order.  A common mechanism is to order the set by the "q"
   parameter value from the Contact header field value.  Requests to the
   URIs MAY be generated serially or in parallel.  One approach is to
   process groups of decreasing q-values serially and process the URIs
   in each q-value group in parallel.  Another is to perform only serial
   processing in decreasing q-value order, arbitrarily choosing between
   contacts of equal q-value.

目標セットが成長するとき、クライアントは順不同なURIに新しい要求を生成するかもしれません。 一般的なメカニズムは「q」パラメタ価値でContactヘッダーフィールド価値からセットを注文することです。 URIへの要求は順次か平行で生成されるかもしれません。 1つのアプローチは、順次、減少しているq-値のグループを処理して、それぞれのq-値のグループにおける平行なURIを処理することです。 別のものは任意に等しいq-価値の接触を選んで、q-値のオーダーを減少させる際に逐次処理だけを実行することになっています。

   If contacting an address in the list results in a failure, as defined
   in the next paragraph, the element moves to the next address in the
   list, until the list is exhausted.  If the list is exhausted, then
   the request has failed.

次のパラグラフで定義されるように失敗におけるリスト結果におけるアドレスに連絡するなら、要素はリストの次のアドレスに移行します、リストが空になるまで。 リストが空になるなら、要求は失敗しました。

Rosenberg, et. al.          Standards Track                    [Page 43]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[43ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Failures SHOULD be detected through failure response codes (codes
   greater than 399); for network errors the client transaction will
   report any transport layer failures to the transaction user.  Note
   that some response codes (detailed in 8.1.3.5) indicate that the
   request can be retried; requests that are reattempted should not be
   considered failures.

失敗SHOULD、失敗応答コード(399以上をコード化する)を通して検出されてください。 ネットワーク誤りによって、クライアントトランザクションはどんなトランスポート層の故障もトランザクションユーザに報告するでしょう。 何らかの応答がコード化する注意、(8.1では、再試行されていた状態で.5が)示す要求があることができる.3を詳しく述べます。 失敗であると「再-試み」られる要求を考えるべきではありません。

   When a failure for a particular contact address is received, the
   client SHOULD try the next contact address.  This will involve
   creating a new client transaction to deliver a new request.

特定の連絡先のための失敗が受け取られているとき、クライアントSHOULDは次の連絡先を試みます。 これは、新しい要求を提供するために新しいクライアントトランザクションを作成することを伴うでしょう。

   In order to create a request based on a contact address in a 3xx
   response, a UAC MUST copy the entire URI from the target set into the
   Request-URI, except for the "method-param" and "header" URI
   parameters (see Section 19.1.1 for a definition of these parameters).
   It uses the "header" parameters to create header field values for the
   new request, overwriting header field values associated with the
   redirected request in accordance with the guidelines in Section
   19.1.5.

連絡先に基づく要求を作成するために、目標からの3xx応答、UAC MUSTコピーの全体のURIはRequest-URIにセットしました、「メソッド-param」と「ヘッダー」URIパラメタを除いて(これらのパラメタの定義に関してセクション19.1.1を見てください)。 それは新しい要求のためにヘッダーフィールド値を作成するのに「ヘッダー」パラメタを使用します、セクション19.1.5におけるガイドラインによると、向け直された要求に関連しているヘッダーフィールド値を上書きして。

   Note that in some instances, header fields that have been
   communicated in the contact address may instead append to existing
   request header fields in the original redirected request.  As a
   general rule, if the header field can accept a comma-separated list
   of values, then the new header field value MAY be appended to any
   existing values in the original redirected request.  If the header
   field does not accept multiple values, the value in the original
   redirected request MAY be overwritten by the header field value
   communicated in the contact address.  For example, if a contact
   address is returned with the following value:

ある場合に、アドレスが代わりに存在するのに追加するかもしれない接触で伝えられたヘッダーフィールドがオリジナルの向け直された要求におけるヘッダーフィールドを要求することに注意してください。 概して、ヘッダーフィールドが値のコンマで切り離されたリストを受け入れることができるなら、オリジナルの向け直された要求におけるどんな既存の値にも新しいヘッダーフィールド値を追加するかもしれません。 ヘッダーフィールドが複数の値を受け入れないなら、オリジナルの向け直された要求における値は連絡先で伝えられたヘッダーフィールド値によって上書きされるかもしれません。 例えば、連絡先がともに帰られるなら、以下は以下を評価します。

      sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

一口: user@host?Subject はfooと等しいです、そして、呼び出しインフォメーションは<http://www.foo.com>と等しいです。

   Then any Subject header field in the original redirected request is
   overwritten, but the HTTP URL is merely appended to any existing
   Call-Info header field values.

次に、オリジナルの向け直された要求におけるどんなSubjectヘッダーフィールドも上書きしますが、単にどんな既存のCall-インフォメーションヘッダーフィールド値にもHTTP URLを追加します。

   It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID
   used in the original redirected request, but the UAC MAY also choose
   to update the Call-ID header field value for new requests, for
   example.

UACが同じTo、From、およびオリジナルの向け直された要求で使用されるCall-IDを再利用しますが、また、UAC MAYが、新しい要求のためにCall-IDヘッダーフィールド価値をアップデートするのを選ぶのは、例えばRECOMMENDEDです。

   Finally, once the new request has been constructed, it is sent using
   a new client transaction, and therefore MUST have a new branch ID in
   the top Via field as discussed in Section 8.1.1.7.

最終的に、新しい要求がいったん構成されると、それは、新しいクライアントトランザクションを使用することで送られて、したがって、セクション8.1.1で.7に議論するように先頭のVia分野に新しいブランチIDを持たなければなりません。

Rosenberg, et. al.          Standards Track                    [Page 44]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[44ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   In all other respects, requests sent upon receipt of a redirect
   response SHOULD re-use the header fields and bodies of the original
   request.

他のすべての点で、再直接の応答SHOULD再使用を受け取り次第要求はオリジナルの要求のヘッダーフィールドとボディーを送りました。

   In some instances, Contact header field values may be cached at UAC
   temporarily or permanently depending on the status code received and
   the presence of an expiration interval; see Sections 21.3.2 and
   21.3.3.

一時的か永久にコードが取った状態と満了間隔の存在によって、ある場合に、Contactヘッダーフィールド値はUACでキャッシュされるかもしれません。 .3にセクション21.3 .2と21.3を見てください。

8.1.3.5 Processing 4xx Responses

8.1.3.5 処理4xx応答

   Certain 4xx response codes require specific UA processing,
   independent of the method.

ある4xx応答コードはメソッドの如何にかかわらず特定のUA処理を必要とします。

   If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
   response is received, the UAC SHOULD follow the authorization
   procedures of Section 22.2 and Section 22.3 to retry the request with
   credentials.

401(権限のない)か407(プロキシAuthentication Required)応答が受け取られているなら、UAC SHOULDは、資格証明書で要求を再試行するためにセクション22.2とセクション22.3の承認手順に従います。

   If a 413 (Request Entity Too Large) response is received (Section
   21.4.11), the request contained a body that was longer than the UAS
   was willing to accept.  If possible, the UAC SHOULD retry the
   request, either omitting the body or using one of a smaller length.

413(Entity Too Largeを要求する)応答が受け取られているなら(セクション21.4.11)、要求はUASが、受け入れても構わないと思っていたより長かったボディーを含みました。 できれば、ボディーを省略するか、または、よりわずかな長さの1つを使用して、UAC SHOULDは要求を再試行します。

   If a 415 (Unsupported Media Type) response is received (Section
   21.4.13), the request contained media types not supported by the UAS.
   The UAC SHOULD retry sending the request, this time only using
   content with types listed in the Accept header field in the response,
   with encodings listed in the Accept-Encoding header field in the
   response, and with languages listed in the Accept-Language in the
   response.

415(サポートされないメディアType)応答が受け取られているなら(セクション21.4.13)、要求はUASによってサポートされなかったメディアタイプを含みました。 UAC SHOULDは要求を送りながら、再試行します、今回が応答におけるAcceptヘッダーフィールドで記載されているタイプ、応答におけるAcceptをコード化しているヘッダーフィールドで記載されているencodings、および応答におけるAccept-言語で記載されている言語と共に内容を使用するだけであって。

   If a 416 (Unsupported URI Scheme) response is received (Section
   21.4.14), the Request-URI used a URI scheme not supported by the
   server.  The client SHOULD retry the request, this time, using a SIP
   URI.

416(サポートされないURI Scheme)応答が受け取られているなら(セクション21.4.14)、Request-URIはサーバによってサポートされなかったURI体系を使用しました。クライアントSHOULDは要求を再試行します、今回、SIP URIを使用して。

   If a 420 (Bad Extension) response is received (Section 21.4.15), the
   request contained a Require or Proxy-Require header field listing an
   option-tag for a feature not supported by a proxy or UAS.  The UAC
   SHOULD retry the request, this time omitting any extensions listed in
   the Unsupported header field in the response.

420(悪いExtension)応答が受け取られているなら、(セクション21.4.15)、要求は、Requireを含んでいるか、またはプロキシかUASによってサポートされなかった特徴のためにオプションタグを記載するヘッダーフィールドをProxy必要とします。 UAC SHOULDはどんな拡大も省略するのがUnsupportedヘッダーフィールドで記載したこの時代に応答で要求を再試行します。

   In all of the above cases, the request is retried by creating a new
   request with the appropriate modifications.  This new request
   constitutes a new transaction and SHOULD have the same value of the
   Call-ID, To, and From of the previous request, but the CSeq should
   contain a new sequence number that is one higher than the previous.

上の場合では、全部で、要求は、適切な変更で新しい要求を作成することによって、再試行されます。 この新しい要求は新しいトランザクションを構成します、そして、SHOULDには、前の要求のCall-ID、To、およびFromの同じ値がありますが、CSeqは前であるより高く1である新しい一連番号を含むはずです。

Rosenberg, et. al.          Standards Track                    [Page 45]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[45ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   With other 4xx responses, including those yet to be defined, a retry
   may or may not be possible depending on the method and the use case.

他の4xx応答、まだ定義されています、再試行がそうするかもしれないか、またはメソッドと使用によって、可能でないかもしれないということでないものがケースに入れる包含で。

8.2 UAS Behavior

8.2 UASの振舞い

   When a request outside of a dialog is processed by a UAS, there is a
   set of processing rules that are followed, independent of the method.
   Section 12 gives guidance on how a UAS can tell whether a request is
   inside or outside of a dialog.

要求であるときに、対話の外部はUASによって処理されて、従われている1セットの処理規則があります、メソッドの如何にかかわらず。 UASが、要求が対話の中か外にあるかどうかどう言うことができるかに関してセクション12は指導を与えます。

   Note that request processing is atomic.  If a request is accepted,
   all state changes associated with it MUST be performed.  If it is
   rejected, all state changes MUST NOT be performed.

要求処理が原子であることに注意してください。 要求を受け入れるなら、それに関連しているすべての州の変化を実行しなければなりません。 それが拒絶されるなら、すべての州の変化を実行しなければならないというわけではありません。

   UASs SHOULD process the requests in the order of the steps that
   follow in this section (that is, starting with authentication, then
   inspecting the method, the header fields, and so on throughout the
   remainder of this section).

UASs SHOULDはこのセクション(すなわち、このセクションの残り中で認証、次に、メソッド、ヘッダーフィールドを点検して、などから始まる)で従う方法の注文における要求を処理します。

8.2.1 Method Inspection

8.2.1 メソッド点検

   Once a request is authenticated (or authentication is skipped), the
   UAS MUST inspect the method of the request.  If the UAS recognizes
   but does not support the method of a request, it MUST generate a 405
   (Method Not Allowed) response.  Procedures for generating responses
   are described in Section 8.2.6.  The UAS MUST also add an Allow
   header field to the 405 (Method Not Allowed) response.  The Allow
   header field MUST list the set of methods supported by the UAS
   generating the message.  The Allow header field is presented in
   Section 20.5.

要求がいったん認証されると(認証はサボられます)、UAS MUSTは要求のメソッドを点検します。 認識しますが、UASが要求のメソッドをサポートしないなら、それは405(メソッドNot Allowed)応答を生成しなければなりません。 応答を生成するための手順はセクション8.2.6で説明されます。 また、UAS MUSTは405(メソッドNot Allowed)応答にAllowヘッダーフィールドを加えます。 Allowヘッダーフィールドはメッセージを生成するUASによってサポートされたメソッドのセットを記載しなければなりません。 Allowヘッダーフィールドはセクション20.5に提示されます。

   If the method is one supported by the server, processing continues.

メソッドがサーバによってサポートされたものであるなら、処理は続きます。

8.2.2 Header Inspection

8.2.2 ヘッダー点検

   If a UAS does not understand a header field in a request (that is,
   the header field is not defined in this specification or in any
   supported extension), the server MUST ignore that header field and
   continue processing the message.  A UAS SHOULD ignore any malformed
   header fields that are not necessary for processing requests.

UASが要求におけるヘッダーフィールドを理解していないなら(すなわち、ヘッダーフィールドはこの仕様かどんなサポートしている拡大でも定義されません)、サーバは、そのヘッダーフィールドを無視して、メッセージを処理し続けなければなりません。 UAS SHOULDはどんな処理要求に必要でない奇形のヘッダーフィールドも無視します。

8.2.2.1 To and Request-URI

8.2.2.1、要求URI

   The To header field identifies the original recipient of the request
   designated by the user identified in the From field.  The original
   recipient may or may not be the UAS processing the request, due to
   call forwarding or other proxy operations.  A UAS MAY apply any
   policy it wishes to determine whether to accept requests when the To

ToヘッダーフィールドはFrom分野で特定されたユーザによって指定された要求のオリジナルの受取人を特定します。 オリジナルの受取人は要求を処理するUASであるかもしれません、自動転送か他のプロキシ操作のため。 UAS MAYはそれがToであるときに、要求を受け入れるかどうか決定したがっているどんな方針も適用します。

Rosenberg, et. al.          Standards Track                    [Page 46]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[46ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   header field is not the identity of the UAS.  However, it is
   RECOMMENDED that a UAS accept requests even if they do not recognize
   the URI scheme (for example, a tel: URI) in the To header field, or
   if the To header field does not address a known or current user of
   this UAS.  If, on the other hand, the UAS decides to reject the
   request, it SHOULD generate a response with a 403 (Forbidden) status
   code and pass it to the server transaction for transmission.

ヘッダーフィールドはUASのアイデンティティではありません。 しかしながら、彼らがToヘッダーフィールドにおけるURI体系(例えば、tel:URI)を認識しないでもUASが要求を受け入れるのが、RECOMMENDEDであるかヘッダーフィールドはToであるならこのUASの知られているか現在のユーザに演説しません。 他方では、UASが、決めるなら、要求を拒絶してください、それ。SHOULDは403(禁じられる)状態がある応答がコードであると生成して、トランスミッションのためにサーバトランザクションにそれを通過します。

   However, the Request-URI identifies the UAS that is to process the
   request.  If the Request-URI uses a scheme not supported by the UAS,
   it SHOULD reject the request with a 416 (Unsupported URI Scheme)
   response.  If the Request-URI does not identify an address that the
   UAS is willing to accept requests for, it SHOULD reject the request
   with a 404 (Not Found) response.  Typically, a UA that uses the
   REGISTER method to bind its address-of-record to a specific contact
   address will see requests whose Request-URI equals that contact
   address.  Other potential sources of received Request-URIs include
   the Contact header fields of requests and responses sent by the UA
   that establish or refresh dialogs.

しかしながら、Request-URIは要求を処理することになっているUASを特定します。 Request-URIがaを使用するなら、体系はUASをサポートしませんでした、それ。SHOULDは416(サポートされないURI Scheme)応答で要求を拒絶します。 Request-URIがアドレスを特定しないなら、UASが要求を受け入れる望みであり、それがSHOULDであることは404(Foundでない)応答で要求を拒絶します。 通常、特定の連絡先に記録されている住所を縛るREGISTERメソッドを使用するUAはRequest-URIがその連絡先と等しい要求を見るでしょう。 容認されたRequest-URIの他の可能な源は対話を確立するか、またはリフレッシュするUAによって送られた要求と応答のContactヘッダーフィールドを含んでいます。

8.2.2.2 Merged Requests

8.2.2.2 合併している要求

   If the request has no tag in the To header field, the UAS core MUST
   check the request against ongoing transactions.  If the From tag,
   Call-ID, and CSeq exactly match those associated with an ongoing
   transaction, but the request does not match that transaction (based
   on the matching rules in Section 17.2.3), the UAS core SHOULD
   generate a 482 (Loop Detected) response and pass it to the server
   transaction.

要求がToヘッダーフィールドでタグを全く持っていないなら、UASコアは進行中のトランザクションに対して要求をチェックしなければなりません。 Fromタグ、Call-ID、およびCSeqがまさに進行中のトランザクションに関連づけられたものに合っていますが、要求がそのトランザクション(セクション17.2.3における合っている規則に基づいている)に合っていないなら、UASコアSHOULDは482(輪のDetected)応答を生成して、サーバトランザクションにそれを通過します。

      The same request has arrived at the UAS more than once, following
      different paths, most likely due to forking.  The UAS processes
      the first such request received and responds with a 482 (Loop
      Detected) to the rest of them.

同じ要求はたぶん分岐のためUASの一度より多くて、次の異なった経路に到着しました。 UASは彼らの残りにそのような要求が受け取った1番目を処理して、482(輪のDetected)で応じます。

8.2.2.3 Require

8.2.2.3、必要

   Assuming the UAS decides that it is the proper element to process the
   request, it examines the Require header field, if present.

UASが、要求を処理するのが、適切な要素であると決めると仮定して、Requireヘッダーフィールドを調べます、存在しているなら。

   The Require header field is used by a UAC to tell a UAS about SIP
   extensions that the UAC expects the UAS to support in order to
   process the request properly.  Its format is described in Section
   20.32.  If a UAS does not understand an option-tag listed in a
   Require header field, it MUST respond by generating a response with
   status code 420 (Bad Extension).  The UAS MUST add an Unsupported
   header field, and list in it those options it does not understand
   amongst those in the Require header field of the request.

Requireヘッダーフィールドは、UACが、UASが適切に要求を処理するためにサポートすると予想するSIP拡張子に関してUASに話すのにUACによって使用されます。 形式はセクション20.32で説明されます。 UASがRequireヘッダーフィールドで記載されたオプションタグを理解していないなら、それは、ステータスコード420(悪いExtension)で応答を生成することによって、応じなければなりません。 UAS MUSTはUnsupportedヘッダーフィールドを加えて、それにそれが要求のRequireヘッダーフィールドにおけるそれらの中で理解していないそれらのオプションを記載します。

Rosenberg, et. al.          Standards Track                    [Page 47]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[47ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
   request, or in an ACK request sent for a non-2xx response.  These
   header fields MUST be ignored if they are present in these requests.

そして、そのRequireに注意してください、中古のコネがSIP CANCEL要求、またはACK要求が非2xx応答のために送ったコネでなければならなかったならProxy必要です。 それらがこれらの要求に存在しているなら、これらのヘッダーフィールドを無視しなければなりません。

   An ACK request for a 2xx response MUST contain only those Require and
   Proxy-Require values that were present in the initial request.

2xx応答を求めるACK要求は、それらのRequireだけを含んでいて、初期の要求に存在している値をProxy必要としなければなりません。

   Example:

例:

      UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
                  Require: 100rel

UAC、-、>UAS: INVITE一口: watson@bell-telephone.com SIP/2.0Require: 100rel

      UAS->UAC:   SIP/2.0 420 Bad Extension
                  Unsupported: 100rel

UAS、-、>UAC: 一口/2.0 420の悪い拡大サポートされない: 100rel

      This behavior ensures that the client-server interaction will
      proceed without delay when all options are understood by both
      sides, and only slow down if options are not understood (as in the
      example above).  For a well-matched client-server pair, the
      interaction proceeds quickly, saving a round-trip often required
      by negotiation mechanisms.  In addition, it also removes ambiguity
      when the client requires features that the server does not
      understand.  Some features, such as call handling fields, are only
      of interest to end systems.

すべてのオプションが両側に解釈されて、オプションが理解されていない場合にだけ減速すると(上記の例のように)、この振舞いは、クライアント/サーバ相互作用が即刻続くのを確実にします。 よく取り組んでいるクライアント/サーバ組のために、相互作用は急速に続きます、節約a往復です。クライアントがサーバが理解していない特徴を必要とするとき、交渉メカニズムIn追加がしばしば必要であることで、また、それはあいまいさを取り除きます。 呼び出し取り扱い分野などのいくつかの特徴が、単にシステムを終わらせるために興味があります。

8.2.3 Content Processing

8.2.3 満足している処理

   Assuming the UAS understands any extensions required by the client,
   the UAS examines the body of the message, and the header fields that
   describe it.  If there are any bodies whose type (indicated by the
   Content-Type), language (indicated by the Content-Language) or
   encoding (indicated by the Content-Encoding) are not understood, and
   that body part is not optional (as indicated by the Content-
   Disposition header field), the UAS MUST reject the request with a 415
   (Unsupported Media Type) response.  The response MUST contain an
   Accept header field listing the types of all bodies it understands,
   in the event the request contained bodies of types not supported by
   the UAS.  If the request contained content encodings not understood
   by the UAS, the response MUST contain an Accept-Encoding header field
   listing the encodings understood by the UAS.  If the request
   contained content with languages not understood by the UAS, the
   response MUST contain an Accept-Language header field indicating the
   languages understood by the UAS.  Beyond these checks, body handling
   depends on the method and type.  For further information on the
   processing of content-specific header fields, see Section 7.4 as well
   as Section 20.11 through 20.15.

UASが、どんな拡大もクライアントが必要であることを理解していると仮定して、UASはメッセージ欄、およびそれについて説明するヘッダーフィールドを調べます。 タイプ(コンテントタイプで、示される)、言語(Content-言語で、示される)またはコード化(Content-コード化で、示される)が理解されていないいくつかのボディーがあって、その身体の部分が任意でないなら(Content気質ヘッダーフィールドによって示されるように)、UAS MUSTは415(サポートされないメディアType)応答で要求を拒絶します。 応答はそれが理解しているすべてのボディーのタイプを記載するAcceptヘッダーフィールドを含まなければならなくて、イベントに、要求はUASによってサポートされなかったタイプのボディーを含みました。 要求がUASに解釈されなかった内容encodingsを含んだなら、応答はUASに解釈されたencodingsを記載するAcceptをコード化しているヘッダーフィールドを含まなければなりません。 要求がUASに解釈されなかった言語がある内容を含んだなら、応答はUASに解釈された言語を示すAccept-言語ヘッダーフィールドを含まなければなりません。 これらのチェックを超えて、ボディー取り扱いはメソッドとタイプに頼っています。 内容特有のヘッダーフィールドの処理の詳細に関しては、また、セクション7.4をセクション20.11〜20.15であるとみなしてください。

Rosenberg, et. al.          Standards Track                    [Page 48]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[48ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

8.2.4 Applying Extensions

8.2.4 拡大を適用すること。

   A UAS that wishes to apply some extension when generating the
   response MUST NOT do so unless support for that extension is
   indicated in the Supported header field in the request.  If the
   desired extension is not supported, the server SHOULD rely only on
   baseline SIP and any other extensions supported by the client.  In
   rare circumstances, where the server cannot process the request
   without the extension, the server MAY send a 421 (Extension Required)
   response.  This response indicates that the proper response cannot be
   generated without support of a specific extension.  The needed
   extension(s) MUST be included in a Require header field in the
   response.  This behavior is NOT RECOMMENDED, as it will generally
   break interoperability.

その拡大のサポートが要求におけるSupportedヘッダーフィールドで示されない場合、応答を生成するとき何らかの拡大を適用したがっているUASはそうしてはいけません。 必要な拡大がサポートされないなら、サーバSHOULDはクライアントによってサポートされた基線SIPといかなる他の拡大だけにも依存します。 まれな事情では、サーバは421(拡大Required)応答を送るかもしれません。そこでは、サーバが拡大なしで要求を処理できません。 この応答は、特定の拡大のサポートなしで適切な応答を生成することができないのを示します。 Requireヘッダーフィールドに応答で必要な拡大を含まなければなりません。 一般に相互運用性を壊すので、この振舞いはNOT RECOMMENDEDです。

   Any extensions applied to a non-421 response MUST be listed in a
   Require header field included in the response.  Of course, the server
   MUST NOT apply extensions not listed in the Supported header field in
   the request.  As a result of this, the Require header field in a
   response will only ever contain option tags defined in standards-
   track RFCs.

応答にヘッダーフィールドを含んでいる場合、Requireに非421応答に適用されたどんな拡大も記載しなければなりません。 もちろん、サーバは要求におけるSupportedヘッダーフィールドで記載されなかった拡大を当てはまってはいけません。 これの結果、応答におけるRequireヘッダーフィールドは規格道のRFCsで定義されたオプションタグを含むだけでしょう。

8.2.5 Processing the Request

8.2.5 要求を処理すること。

   Assuming all of the checks in the previous subsections are passed,
   the UAS processing becomes method-specific.  Section 10 covers the
   REGISTER request, Section 11 covers the OPTIONS request, Section 13
   covers the INVITE request, and Section 15 covers the BYE request.

前の小区分におけるチェックのすべてが通過されると仮定して、UAS処理はメソッド特有になります。 REGISTERが要求するセクション10カバー、OPTIONSが要求するセクション11カバー、セクション13はINVITE要求をカバーします、そして、セクション15はBYE要求をカバーします。

8.2.6 Generating the Response

8.2.6 応答を生成すること。

   When a UAS wishes to construct a response to a request, it follows
   the general procedures detailed in the following subsections.
   Additional behaviors specific to the response code in question, which
   are not detailed in this section, may also be required.

UASが要求への応答を構成したがっているとき、それは以下の小区分で詳細な基本手順に従います。 また、問題の応答コードに特定の追加振舞い(このセクションで詳しく述べられない)が必要であるかもしれません。

   Once all procedures associated with the creation of a response have
   been completed, the UAS hands the response back to the server
   transaction from which it received the request.

応答の作成に関連しているすべての手順がいったん完了すると、UASはそれが要求を受け取ったサーバトランザクションに応答を返します。

8.2.6.1 Sending a Provisional Response

8.2.6.1 暫定的な応答を送ること。

   One largely non-method-specific guideline for the generation of
   responses is that UASs SHOULD NOT issue a provisional response for a
   non-INVITE request.  Rather, UASs SHOULD generate a final response to
   a non-INVITE request as soon as possible.

1つ、応答の世代単位で非メソッドの詳細ガイドラインは主に、UASs SHOULDが非INVITE要求のための暫定的な応答を発行しないということです。 むしろ、UASs SHOULDはできるだけ早く、非INVITE要求への最終的な応答を生成します。

Rosenberg, et. al.          Standards Track                    [Page 49]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[49ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   When a 100 (Trying) response is generated, any Timestamp header field
   present in the request MUST be copied into this 100 (Trying)
   response.  If there is a delay in generating the response, the UAS
   SHOULD add a delay value into the Timestamp value in the response.
   This value MUST contain the difference between the time of sending of
   the response and receipt of the request, measured in seconds.

100の(試みること)の応答が発生しているとき、この100の(試みること)の応答に要求の現在のどんなTimestampヘッダーフィールドもコピーしなければなりません。 応答を生成する遅れがあれば、UAS SHOULDは応答におけるTimestamp値に遅れ価値を高めます。 この値は応答を発信させる時間と要求の領収書の秒に測定された違いを含まなければなりません。

8.2.6.2 Headers and Tags

8.2.6.2 ヘッダーとタグ

   The From field of the response MUST equal the From header field of
   the request.  The Call-ID header field of the response MUST equal the
   Call-ID header field of the request.  The CSeq header field of the
   response MUST equal the CSeq field of the request.  The Via header
   field values in the response MUST equal the Via header field values
   in the request and MUST maintain the same ordering.

応答のFrom分野は要求のFromヘッダーフィールドと等しくなければなりません。 応答のCall-IDヘッダーフィールドは要求のCall-IDヘッダーフィールドと等しくなければなりません。 応答のCSeqヘッダーフィールドは要求のCSeq分野と等しくなければなりません。 応答におけるViaヘッダーフィールド値は、要求におけるViaヘッダーフィールド値と等しくなければならなく、同じ注文を維持しなければなりません。

   If a request contained a To tag in the request, the To header field
   in the response MUST equal that of the request.  However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present).  This serves to identify the UAS that is
   responding, possibly resulting in a component of a dialog ID.  The
   same tag MUST be used for all responses to that request, both final
   and provisional (again excepting the 100 (Trying)).  Procedures for
   the generation of tags are defined in Section 19.3.

要求が要求にToタグを含んだなら、応答におけるToヘッダーフィールドは要求のものと等しくなければなりません。 しかしながら、要求におけるToヘッダーフィールドがタグを含まなかったなら、応答におけるToヘッダーフィールドにおけるURIはToヘッダーフィールドにおけるURIと等しくなければなりません。 さらに、UAS MUSTは応答(タグが現在であるかもしれない100の(試みること)の応答を除いた)におけるToヘッダーフィールドにタグを加えます。 これは、ことによると対話IDの成分をもたらして、応じているUASを特定するのに役立ちます。 同じタグは、その要求へのすべての応答に中古で、かつ最終的で、かつ暫定的であるに違いありません(再び、100(トライ)を除きます)。 タグの世代のための手順はセクション19.3で定義されます。

8.2.7 Stateless UAS Behavior

8.2.7 状態がないUASの振舞い

   A stateless UAS is a UAS that does not maintain transaction state.
   It replies to requests normally, but discards any state that would
   ordinarily be retained by a UAS after a response has been sent.  If a
   stateless UAS receives a retransmission of a request, it regenerates
   the response and resends it, just as if it were replying to the first
   instance of the request. A UAS cannot be stateless unless the request
   processing for that method would always result in the same response
   if the requests are identical. This rules out stateless registrars,
   for example.  Stateless UASs do not use a transaction layer; they
   receive requests directly from the transport layer and send responses
   directly to the transport layer.

状態がないUASはトランザクション状態を維持しないUASです。 それは、通常要求に答えますが、応答を送った後に通常、UASが保有するどんな状態も捨てます。 状態がないUASが要求の「再-トランスミッション」を受けるなら、応答を作り直して、それを再送します、まるでまさしく要求の最初のインスタンスに答えているかのように。 要求が同じであるならそのメソッドのための要求処理がいつも同じ応答をもたらすというわけではないなら、UASは状態がないはずがありません。 これは例えば状態がない記録係を除外します。 状態がないUASsはトランザクション層を使用しません。 彼らは、直接トランスポート層から要求を受け取って、直接トランスポート層に応答を送ります。

   The stateless UAS role is needed primarily to handle unauthenticated
   requests for which a challenge response is issued.  If
   unauthenticated requests were handled statefully, then malicious
   floods of unauthenticated requests could create massive amounts of

状態がないUASの役割が、主としてチャレンジレスポンスが発行される非認証された要求を扱うのに必要です。 非認証された要求が要求が大規模な量を作成できた非認証されることの扱われたstatefullyであって、次に、悪意がある洪水であったなら

Rosenberg, et. al.          Standards Track                    [Page 50]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[50ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   transaction state that might slow or completely halt call processing
   in a UAS, effectively creating a denial of service condition; for
   more information see Section 26.1.5.

事実上、運転条件の否定を作成して、UASで呼び出し処理を遅くするか、または完全止めるかもしれないトランザクション州。 詳しい情報に関しては、セクション26.1.5を見てください。

   The most important behaviors of a stateless UAS are the following:

状態がないUASの最も重要な振舞いは以下です:

      o  A stateless UAS MUST NOT send provisional (1xx) responses.

o 状態がないUAS MUST NOTは暫定的な(1xx)応答を送ります。

      o  A stateless UAS MUST NOT retransmit responses.

o 状態がないUAS MUST NOTは応答を再送します。

      o  A stateless UAS MUST ignore ACK requests.

o 状態がないUAS MUSTはACK要求を無視します。

      o  A stateless UAS MUST ignore CANCEL requests.

o 状態がないUAS MUSTはキャンセル要求を無視します。

      o  To header tags MUST be generated for responses in a stateless
         manner - in a manner that will generate the same tag for the
         same request consistently.  For information on tag construction
         see Section 19.3.

o 状態がない方法、同じ要求のために一貫して同じタグを生成する方法における応答のためにヘッダータグに生成しなければなりません。 タグ工事の情報に関しては、セクション19.3を見てください。

   In all other respects, a stateless UAS behaves in the same manner as
   a stateful UAS.  A UAS can operate in either a stateful or stateless
   mode for each new request.

他のすべての点で、状態がないUASはstateful UASと同じ態度で振る舞います。 UASはそれぞれの新しい要求のためのstatefulか状態がないモードのどちらかで作動できます。

8.3 Redirect Servers

8.3 再直接のサーバ

   In some architectures it may be desirable to reduce the processing
   load on proxy servers that are responsible for routing requests, and
   improve signaling path robustness, by relying on redirection.

いくつかのアーキテクチャでは、ルーティング要求に原因となるプロキシサーバで処理負荷を減少させて、向上するのは経路丈夫さに合図しながら、望ましいかもしれません、リダイレクションを当てにすることによって。

   Redirection allows servers to push routing information for a request
   back in a response to the client, thereby taking themselves out of
   the loop of further messaging for this transaction while still aiding
   in locating the target of the request.  When the originator of the
   request receives the redirection, it will send a new request based on
   the URI(s) it has received.  By propagating URIs from the core of the
   network to its edges, redirection allows for considerable network
   scalability.

サーバはリダイレクションでクライアントへの応答で要求のためのルーティング情報を押し戻すことができます、その結果、このトランザクションのために要求の目標の場所を見つける際にまだ支援している間、さらに通信する輪から自分たちを取り出します。 要求の創始者がリダイレクションを受けるとき、それはそれが受けたURIに基づく新しい要求を送るでしょう。 ネットワークのコアから縁までURIを伝播することによって、リダイレクションはかなりのネットワークスケーラビリティを考慮します。

   A redirect server is logically constituted of a server transaction
   layer and a transaction user that has access to a location service of
   some kind (see Section 10 for more on registrars and location
   services).  This location service is effectively a database
   containing mappings between a single URI and a set of one or more
   alternative locations at which the target of that URI can be found.

再直接のサーバはサーバトランザクション層とある種の位置のサービスに近づく手段を持っているトランザクションユーザに論理的に構成されます(詳しい情報については、記録係と位置のサービスにセクション10を見てください)。 事実上、この位置のサービスはそのURIの目標を見つけることができる1つ以上の代替の位置のただ一つのURIとセットの間にマッピングを含むデータベースです。

   A redirect server does not issue any SIP requests of its own.  After
   receiving a request other than CANCEL, the server either refuses the
   request or gathers the list of alternative locations from the

再直接のサーバはそれ自身のどんなSIP要求も出しません。 キャンセル以外の要求、どちらかが要求を拒否するか、または代替の位置のリストを集めるサーバを受け取ること。

Rosenberg, et. al.          Standards Track                    [Page 51]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[51ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   location service and returns a final response of class 3xx.  For
   well-formed CANCEL requests, it SHOULD return a 2xx response.  This
   response ends the SIP transaction.  The redirect server maintains
   transaction state for an entire SIP transaction.  It is the
   responsibility of clients to detect forwarding loops between redirect
   servers.

位置は、クラス3xxの最終的な応答を修理して、返します。 整形式のキャンセル要求のためにそれ、SHOULDは2xx応答を返します。 この応答はSIPトランザクションを終わらせます。 再直接のサーバは全体のSIPトランザクションのためにトランザクション状態を維持します。 再直接のサーバの間の推進輪を検出するのは、クライアントの責任です。

   When a redirect server returns a 3xx response to a request, it
   populates the list of (one or more) alternative locations into the
   Contact header field.  An "expires" parameter to the Contact header
   field values may also be supplied to indicate the lifetime of the
   Contact data.

再直接のサーバが要求への3xx応答を返すとき、それは(1以上)代替の位置のリストにContactヘッダーフィールドに居住します。 また、Contactデータの生涯を示すためにContactヘッダーフィールド値への「期限が切れ」パラメタを提供するかもしれません。

   The Contact header field contains URIs giving the new locations or
   user names to try, or may simply specify additional transport
   parameters.  A 301 (Moved Permanently) or 302 (Moved Temporarily)
   response may also give the same location and username that was
   targeted by the initial request but specify additional transport
   parameters such as a different server or multicast address to try, or
   a change of SIP transport from UDP to TCP or vice versa.

Contactヘッダーフィールドは、試みるために新しい位置かユーザに名前を与えるURIを含んでいるか、または単に追加輸送パラメタを指定するかもしれません。 301(Permanentlyを動かす)か302(Temporarilyを動かす)応答が、また、初期の要求で狙った同じ位置とユーザ名を与えますが、試みる異なったサーバかマルチキャストアドレスなどの追加輸送パラメタ、またはSIP輸送のUDPからTCPまでの変化を指定するかもしれませんか、逆もまた同様です。

   However, redirect servers MUST NOT redirect a request to a URI equal
   to the one in the Request-URI; instead, provided that the URI does
   not point to itself, the server MAY proxy the request to the
   destination URI, or MAY reject it with a 404.

しかしながら、再直接のサーバはRequest-URIでものと等しいURIに要求を向け直してはいけません。 URIが目的地URI、または5月までの要求をそれ自体、サーバ5月のプロキシに向けなければ、代わりに、404でそれを拒絶してください。

      If a client is using an outbound proxy, and that proxy actually
      redirects requests, a potential arises for infinite redirection
      loops.

クライアントが外国行きのプロキシを使用していて、そのプロキシが実際に要求を向け直すなら、可能性は無限のリダイレクション輪のために起こります。

   Note that a Contact header field value MAY also refer to a different
   resource than the one originally called.  For example, a SIP call
   connected to PSTN gateway may need to deliver a special informational
   announcement such as "The number you have dialed has been changed."

また、Contactヘッダーフィールド価値が元々呼ばれたものと異なったリソースを示すかもしれないことに注意してください。 例えば、PSTNゲートウェイへのSIP接続完了は、「あなたがダイヤルした番号を変えなどだったことなど」の特別な情報の発表を提供する必要があるかもしれません。

   A Contact response header field can contain any suitable URI
   indicating where the called party can be reached, not limited to SIP
   URIs.  For example, it could contain URIs for phones, fax, or irc (if
   they were defined) or a mailto:  (RFC 2368 [32]) URL.  Section 26.4.4
   discusses implications and limitations of redirecting a SIPS URI to a
   non-SIPS URI.

Contact応答ヘッダーフィールドはSIP URIに制限されるのではなく、どこに被呼者に連絡できるかを示すどんな適当なURIも含むことができます。 例えば、電話、ファックス、irc(それらが定義されたなら)またはmailtoのためのURIを含むかもしれません: (RFC2368[32]) URL。 セクション26.4 .4 非SIPS URIにSIPS URIを向け直す含意と制限について議論します。

   The "expires" parameter of a Contact header field value indicates how
   long the URI is valid.  The value of the parameter is a number
   indicating seconds.  If this parameter is not provided, the value of
   the Expires header field determines how long the URI is valid.
   Malformed values SHOULD be treated as equivalent to 3600.

Contactヘッダーフィールド価値の「期限が切れ」パラメタは、URIがどれくらい長い間有効であるかを示します。 パラメタの値は秒を示す数です。 このパラメタが提供されないなら、Expiresヘッダーフィールドの値は、URIがどれくらい長い間有効であるかを決定します。 奇形、3600と同等物として扱われた状態でSHOULDを評価します。

Rosenberg, et. al.          Standards Track                    [Page 52]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[52ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      This provides a modest level of backwards compatibility with RFC
      2543, which allowed absolute times in this header field.  If an
      absolute time is received, it will be treated as malformed, and
      then default to 3600.

これはRFC2543との互換性を後方にの穏やかなレベルに提供します。(RFCはこのヘッダーフィールドにおける絶対回を許容しました)。 絶対時間が受け取られていると、それは、奇形として扱われて、3600をデフォルトとするでしょう。

   Redirect servers MUST ignore features that are not understood
   (including unrecognized header fields, any unknown option tags in
   Require, or even method names) and proceed with the redirection of
   the request in question.

再直接のサーバは、理解されていない(認識されていないヘッダーフィールド、Requireのどんな未知のオプションタグ、またはメソッド名さえも含んでいます)特徴を無視して、問題の要求のリダイレクションを続けなければなりません。

9 Canceling a Request

9 要求を中止すること。

   The previous section has discussed general UA behavior for generating
   requests and processing responses for requests of all methods.  In
   this section, we discuss a general purpose method, called CANCEL.

前項は要求と処理がすべてのメソッドの要求のための応答であると生成するための一般的なUAの振舞いについて議論しました。 このセクションで、私たちはキャンセルと呼ばれる汎用のメソッドについて議論します。

   The CANCEL request, as the name implies, is used to cancel a previous
   request sent by a client.  Specifically, it asks the UAS to cease
   processing the request and to generate an error response to that
   request.  CANCEL has no effect on a request to which a UAS has
   already given a final response.  Because of this, it is most useful
   to CANCEL requests to which it can take a server long time to
   respond.  For this reason, CANCEL is best for INVITE requests, which
   can take a long time to generate a response.  In that usage, a UAS
   that receives a CANCEL request for an INVITE, but has not yet sent a
   final response, would "stop ringing", and then respond to the INVITE
   with a specific error response (a 487).

名前が含意するようにキャンセル要求は、クライアントによって送られた前の要求を中止するのに使用されます。 明確に、それは、要求を処理するのをやめて、その要求への誤り応答を生成するようにUASに頼みます。 キャンセルはUASが既に最終的な応答を与えた要求のときに効き目がありません。 これのために、それは長い時に応じるのにサーバを要することができるキャンセル要求の最も役に立ちます。 この理由で、INVITE要求に、キャンセルは最も良いです。(要求は、応答を生成するには長い時かかるかもしれません)。 その用法で、INVITEを求めるキャンセル要求を受け取りますが、まだ最終的な応答を送らないUASは「鳴るのを止め」て、次に、特定の誤り応答(487)でINVITEに応じるでしょう。

   CANCEL requests can be constructed and sent by both proxies and user
   agent clients.  Section 15 discusses under what conditions a UAC
   would CANCEL an INVITE request, and Section 16.10 discusses proxy
   usage of CANCEL.

プロキシとユーザエージェントのクライアントの両方でキャンセル要求を構成して、送ることができます。 UACはどんな状態がそうするだろうかの下でセクション15はINVITEが要求するキャンセルについて論じます、そして、セクション16.10はキャンセルのプロキシ用法について議論します。

   A stateful proxy responds to a CANCEL, rather than simply forwarding
   a response it would receive from a downstream element.  For that
   reason, CANCEL is referred to as a "hop-by-hop" request, since it is
   responded to at each stateful proxy hop.

statefulプロキシは単にそれが下流要素から受ける応答を進めるよりむしろキャンセルに応じます。 その理由で、キャンセルは「ホップごとの」要求と呼ばれます、それがそれぞれのstatefulプロキシを跳ぶために反応するので。

9.1 Client Behavior

9.1 クライアントの振舞い

   A CANCEL request SHOULD NOT be sent to cancel a request other than
   INVITE.

キャンセルは、SHOULD NOTがINVITE以外の要求を中止するために送られるよう要求します。

      Since requests other than INVITE are responded to immediately,
      sending a CANCEL for a non-INVITE request would always create a
      race condition.

INVITE以外の要求がすぐに反応するので、非INVITE要求のためのキャンセルを送ると、競合条件はいつも作成されるでしょう。

Rosenberg, et. al.          Standards Track                    [Page 53]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[53ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The following procedures are used to construct a CANCEL request.  The
   Request-URI, Call-ID, To, the numeric part of CSeq, and From header
   fields in the CANCEL request MUST be identical to those in the
   request being cancelled, including tags.  A CANCEL constructed by a
   client MUST have only a single Via header field value matching the
   top Via value in the request being cancelled.  Using the same values
   for these header fields allows the CANCEL to be matched with the
   request it cancels (Section 9.2 indicates how such matching occurs).
   However, the method part of the CSeq header field MUST have a value
   of CANCEL.  This allows it to be identified and processed as a
   transaction in its own right (See Section 17).

以下の手順は、キャンセル要求を構成するのに用いられます。 Request-URI、Call-ID、To、CSeqの数値部分、およびキャンセル要求におけるFromヘッダーフィールドは中止される要求におけるそれらと同じであるに違いありません、タグを含んでいて。 クライアントによって構成されたキャンセルは中止される要求における最高Via値に合っているただ一つのViaヘッダーフィールド価値しか持ってはいけません。 これらのヘッダーフィールドに同じ値を使用するのに、キャンセルはそれが中止する要求に合っています(セクション9.2は、そのようなマッチングがどのように起こるかを示します)。 しかしながら、CSeqヘッダーフィールドのメソッド部分には、キャンセルの値がなければなりません。 これは、それがトランザクションとしてそれ自体で特定されて、処理されるのを許容します(セクション17を見てください)。

   If the request being cancelled contains a Route header field, the
   CANCEL request MUST include that Route header field's values.

中止される要求がRouteヘッダーフィールドを含んでいるなら、キャンセル要求はそのRouteヘッダーフィールドの値を含まなければなりません。

      This is needed so that stateless proxies are able to route CANCEL
      requests properly.

これが必要であるので、状態がないプロキシは適切にキャンセル要求を発送できます。

   The CANCEL request MUST NOT contain any Require or Proxy-Require
   header fields.

キャンセル要求は、どんなRequireも含んではいけませんし、またヘッダーフィールドをProxy必要としてはいけません。

   Once the CANCEL is constructed, the client SHOULD check whether it
   has received any response (provisional or final) for the request
   being cancelled (herein referred to as the "original request").

それが中止される(ここに「オリジナルの要求」と呼ばれます)要求のためにどんな応答も受けた(暫定的であるか最終的な)か否かに関係なく、クライアントSHOULDは、一度、キャンセルが構成されるのをチェックします。

   If no provisional response has been received, the CANCEL request MUST
   NOT be sent; rather, the client MUST wait for the arrival of a
   provisional response before sending the request.  If the original
   request has generated a final response, the CANCEL SHOULD NOT be
   sent, as it is an effective no-op, since CANCEL has no effect on
   requests that have already generated a final response.  When the
   client decides to send the CANCEL, it creates a client transaction
   for the CANCEL and passes it the CANCEL request along with the
   destination address, port, and transport.  The destination address,
   port, and transport for the CANCEL MUST be identical to those used to
   send the original request.

どんな暫定的な応答も受けていないなら、キャンセル要求を送ってはいけません。 むしろ、要求を送る前に、クライアントは暫定的な応答の到着を待たなければなりません。 オリジナルの要求が最終的な応答を生成したなら、それが有効なオプアートでないのでCANCEL SHOULD NOTを送って、キャンセルが影響を全くオンに与えないので、そうした要求は既に最終的な応答を生成しました。 クライアントが、キャンセルを送ると決めると、それは、キャンセルのためにクライアントトランザクションを作成して、送付先アドレス、ポート、および輸送と共にキャンセル要求にそれに合格します。 キャンセルのための送付先アドレス、ポート、および輸送はオリジナルの要求を送るのに使用されるものと同じであるに違いありません。

      If it was allowed to send the CANCEL before receiving a response
      for the previous request, the server could receive the CANCEL
      before the original request.

前の要求のための応答を受ける前にキャンセルを送ることができるなら、サーバはオリジナルの要求の前にキャンセルを受けるかもしれないでしょうに。

   Note that both the transaction corresponding to the original request
   and the CANCEL transaction will complete independently.  However, a
   UAC canceling a request cannot rely on receiving a 487 (Request
   Terminated) response for the original request, as an RFC 2543-
   compliant UAS will not generate such a response.  If there is no
   final response for the original request in 64*T1 seconds (T1 is

オリジナルの要求に対応するトランザクションとキャンセルトランザクションの両方が独自に完成する注意。 しかしながら、要求を中止するUACはオリジナルの要求のための487(Terminatedを要求する)応答を受けるのを当てにすることができません、RFC2543の言いなりになっているUASがそのような応答を生成しないとき。 64*T1秒でオリジナルの要求のためのどんな最終的な応答もない、(T1はそうです。

Rosenberg, et. al.          Standards Track                    [Page 54]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[54ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   defined in Section 17.1.1.1), the client SHOULD then consider the
   original transaction cancelled and SHOULD destroy the client
   transaction handling the original request.

セクション17.1で定義されて、.1、)そしてクライアントSHOULDが、オリジナルのトランザクションが取り消したと考える.1とSHOULDはオリジナルの要求を扱うクライアントトランザクションを破壊します。

9.2 Server Behavior

9.2 サーバの振舞い

   The CANCEL method requests that the TU at the server side cancel a
   pending transaction.  The TU determines the transaction to be
   cancelled by taking the CANCEL request, and then assuming that the
   request method is anything but CANCEL or ACK and applying the
   transaction matching procedures of Section 17.2.3.  The matching
   transaction is the one to be cancelled.

キャンセルメソッドは、サーバ側のTUが未定のトランザクションを取り消すよう要求します。 TUは、キャンセル要求を取って、次に、要求メソッドがキャンセルかACK以外の何とでもセクション17.2.3の手順を合わせながらトランザクションを適用することであると仮定することによってトランザクションが取り消されることを決定します。 マッチング取引は取り消されるべきものです。

   The processing of a CANCEL request at a server depends on the type of
   server.  A stateless proxy will forward it, a stateful proxy might
   respond to it and generate some CANCEL requests of its own, and a UAS
   will respond to it.  See Section 16.10 for proxy treatment of CANCEL.

サーバにおけるキャンセル要求の処理はサーバのタイプに頼っています。状態がないプロキシはそれを送るでしょう、そして、statefulプロキシは、それにこたえて、何らかのキャンセルがそれ自身の要求であると生成するかもしれません、そして、UASはそれにこたえるでしょう。 キャンセルのプロキシ処理に関してセクション16.10を見てください。

   A UAS first processes the CANCEL request according to the general UAS
   processing described in Section 8.2.  However, since CANCEL requests
   are hop-by-hop and cannot be resubmitted, they cannot be challenged
   by the server in order to get proper credentials in an Authorization
   header field.  Note also that CANCEL requests do not contain a
   Require header field.

セクション8.2で説明された一般的なUAS処理に従って、UASは最初に、キャンセル要求を処理します。 しかしながら、ホップであることごとにキャンセル要求を再提出できないので、サーバはAuthorizationヘッダーフィールドにおける適切な資格証明書を得るためにそれらに挑戦できません。 また、キャンセル要求がRequireヘッダーフィールドを含まないことに注意してください。

   If the UAS did not find a matching transaction for the CANCEL
   according to the procedure above, it SHOULD respond to the CANCEL
   with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction
   for the original request still exists, the behavior of the UAS on
   receiving a CANCEL request depends on whether it has already sent a
   final response for the original request.  If it has, the CANCEL
   request has no effect on the processing of the original request, no
   effect on any session state, and no effect on the responses generated
   for the original request.  If the UAS has not issued a final response
   for the original request, its behavior depends on the method of the
   original request.  If the original request was an INVITE, the UAS
   SHOULD immediately respond to the INVITE with a 487 (Request
   Terminated).  A CANCEL request has no impact on the processing of
   transactions with any other method defined in this specification.

UASがそうしなかったなら、手順に従って、上でキャンセルのためのマッチング取引を見つけてください、それ。SHOULDは481でキャンセルに応じます(Does Not ExistにLeg/取引に電話をしてください)。 オリジナルの要求のための取引がまだ存在しているなら、キャンセル要求を受け取るときのUASの動きはオリジナルの要求のためにそれが既に最終的な応答を送ったかどうかによります。 そうしたなら、キャンセル要求はオリジナルの要求(状態を発生させますが、応答へのどんな効果もオリジナルの要求のために発生させなかったどんなセッションへの効果がありませんも)の処理のときに効き目がありません。 UASがオリジナルの要求のための最終的な応答を発行していないなら、振舞いはオリジナルの要求の方法によります。 オリジナルの要求がINVITEであったなら、UAS SHOULDはすぐに、487でINVITEに応じます(Terminatedを要求してください)。 キャンセル要求はいかなる他の方法もこの仕様に基づき定義されている取引の処理に変化も与えません。

   Regardless of the method of the original request, as long as the
   CANCEL matched an existing transaction, the UAS answers the CANCEL
   request itself with a 200 (OK) response.  This response is
   constructed following the procedures described in Section 8.2.6
   noting that the To tag of the response to the CANCEL and the To tag
   in the response to the original request SHOULD be the same.  The
   response to CANCEL is passed to the server transaction for
   transmission.

オリジナルの要求の方法にかかわらず、キャンセルが既存の取引に合っていた限り、UASは200(OK)応答でキャンセル要求自体に答えます。 キャンセルへの応答のToタグとオリジナルの要求SHOULDへの応答におけるToタグが同じであることに注意するセクション8.2.6で説明された手順に従って、この応答は構成されます。 キャンセルへの応答はトランスミッションのためのサーバ取引に通過されます。

Rosenberg, et. al.          Standards Track                    [Page 55]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[55ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

10 Registrations

10の登録証明書

10.1 Overview

10.1 概観

   SIP offers a discovery capability.  If a user wants to initiate a
   session with another user, SIP must discover the current host(s) at
   which the destination user is reachable.  This discovery process is
   frequently accomplished by SIP network elements such as proxy servers
   and redirect servers which are responsible for receiving a request,
   determining where to send it based on knowledge of the location of
   the user, and then sending it there.  To do this, SIP network
   elements consult an abstract service known as a location service,
   which provides address bindings for a particular domain.  These
   address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com,
   for example, to one or more URIs that are somehow "closer" to the
   desired user, sip:bob@engineering.biloxi.com, for example.
   Ultimately, a proxy will consult a location service that maps a
   received URI to the user agent(s) at which the desired recipient is
   currently residing.

SIPは発見能力を提供します。 ユーザが別のユーザとのセッションを開始したいと思うなら、SIPは目的地ユーザが届いている現在のホストを発見しなければなりません。 この発見の過程は頻繁に要求を受け取るのに原因となるプロキシサーバや再直接のサーバなどのSIPネットワーク原理によって達成されます、それがユーザの位置に関する知識に基づいていて、次に、それをそこに送るのをどこに送るかを決定して。 これをするために、SIPネットワーク要素は位置のサービスとして知られている抽象的なサービスに相談します。それは、特定のドメインのためのアドレス結合を提供します。 これらのアドレス結合は入って来るSIPかSIPS URIを写像します、一口: 例えばどうにか一口: 必要なユーザ、例えば、 bob@engineering.biloxi.com に「より近い」1つ以上のURIへの bob@biloxi.com 。 結局、プロキシは必要な受取人が現在住んでいるユーザエージェントに容認されたURIを写像する位置のサービスに相談するでしょう。

   Registration creates bindings in a location service for a particular
   domain that associates an address-of-record URI with one or more
   contact addresses.  Thus, when a proxy for that domain receives a
   request whose Request-URI matches the address-of-record, the proxy
   will forward the request to the contact addresses registered to that
   address-of-record.  Generally, it only makes sense to register an
   address-of-record at a domain's location service when requests for
   that address-of-record would be routed to that domain.  In most
   cases, this means that the domain of the registration will need to
   match the domain in the URI of the address-of-record.

登録は記録されている住所URIを1つ以上の連絡先に関連づける特定のドメインのための位置のサービスにおける結合を作成します。 そのドメインへのプロキシがRequest-URIが記録されている住所に合っている要求を受け取るとき、したがって、プロキシはその記録されている住所に登録された連絡先に要求を転送するでしょう。 一般に、それはその記録されている住所を求める要求がそのドメインに発送されるだろうというときドメインの位置のサービスで記録されている住所を登録する意味になるだけです。 多くの場合、これは、登録のドメインが、記録されている住所のURIにおけるドメインを合わせる必要を意味します。

   There are many ways by which the contents of the location service can
   be established.  One way is administratively.  In the above example,
   Bob is known to be a member of the engineering department through
   access to a corporate database.  However, SIP provides a mechanism
   for a UA to create a binding explicitly.  This mechanism is known as
   registration.

位置のサービスのコンテンツを確立できる多くの方法があります。 1つの方法が行政上そうです。 上記の例では、ボブは法人のデータベースへのアクセスによる工学部のメンバーであることが知られています。 しかしながら、UAが明らかに結合を作成するように、SIPはメカニズムを提供します。 このメカニズムは登録として知られています。

   Registration entails sending a REGISTER request to a special type of
   UAS known as a registrar.  A registrar acts as the front end to the
   location service for a domain, reading and writing mappings based on
   the contents of REGISTER requests.  This location service is then
   typically consulted by a proxy server that is responsible for routing
   requests for that domain.

登録は、記録係として知られているUASの特別なタイプにREGISTER要求を送るのを伴います。 ドメイン、読書、および書くことのマッピングのための位置のサービスへのフロントエンドが要求をREGISTERのコンテンツに基礎づけて、記録係は行動します。 そして、この位置のサービスはそのドメインを求めるルーティング要求に原因となるプロキシサーバによって通常相談されます。

   An illustration of the overall registration process is given in
   Figure 2.  Note that the registrar and proxy server are logical roles
   that can be played by a single device in a network; for purposes of

図2で総合的な登録手続のイラストを与えます。 記録係とプロキシサーバが単一の装置でネットワークで果たすことができる論理的な役割であることに注意してください。 目的

Rosenberg, et. al.          Standards Track                    [Page 56]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[56ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   clarity the two are separated in this illustration.  Also note that
   UAs may send requests through a proxy server in order to reach a
   registrar if the two are separate elements.

明快である、2はこのイラストで切り離されます。 また、UAsが2が別々の要素であるなら記録係に届くようにプロキシサーバを通して要求を送るかもしれないことに注意してください。

   SIP does not mandate a particular mechanism for implementing the
   location service.  The only requirement is that a registrar for some
   domain MUST be able to read and write data to the location service,
   and a proxy or a redirect server for that domain MUST be capable of
   reading that same data.  A registrar MAY be co-located with a
   particular SIP proxy server for the same domain.

SIPは、位置のサービスを実行するために特定のメカニズムを強制しません。 唯一の要件は何らかのドメインへの記録係が位置のサービスにデータを読み書きできなければならないということです、そして、そのドメインへのプロキシか再直接のサーバがその同じデータを読むことができなければなりません。 記録係は同じドメインへの特定のSIPプロキシサーバで共同見つけられるかもしれません。

10.2 Constructing the REGISTER Request

10.2 レジスタ要求を構成すること。

   REGISTER requests add, remove, and query bindings.  A REGISTER
   request can add a new binding between an address-of-record and one or
   more contact addresses.  Registration on behalf of a particular
   address-of-record can be performed by a suitably authorized third
   party.  A client can also remove previous bindings or query to
   determine which bindings are currently in place for an address-of-
   record.

REGISTER要求は、結合を加えて、取り除いて、質問します。 REGISTER要求は記録されている住所と1つ以上の連絡先の間の新しい結合を加えることができます。 適当に認可された第三者は特定の記録されている住所を代表した登録を実行できます。 また、クライアントが現在アドレスのために適所で結合がどれであるかを決定するために前の結合か質問を取り除くことができる、-、記録について。

   Except as noted, the construction of the REGISTER request and the
   behavior of clients sending a REGISTER request is identical to the
   general UAC behavior described in Section 8.1 and Section 17.1.

注意されるのを除いて、REGISTER要求の工事とREGISTER要求を送るクライアントの振舞いはセクション8.1とセクション17.1で説明された一般的なUACの振舞いと同じです。

   A REGISTER request does not establish a dialog.  A UAC MAY include a
   Route header field in a REGISTER request based on a pre-existing
   route set as described in Section 8.1.  The Record-Route header field
   has no meaning in REGISTER requests or responses, and MUST be ignored
   if present.  In particular, the UAC MUST NOT create a new route set
   based on the presence or absence of a Record-Route header field in
   any response to a REGISTER request.

REGISTER要求は対話を確立しません。 UAC MAYはセクション8.1で説明されるように先在のルートセットに基づくREGISTER要求にRouteヘッダーフィールドを含んでいます。 Record-ルートヘッダーフィールドをREGISTER要求か応答における意味でないのを持って、存在しているなら、無視しなければなりません。 特に、UAC MUST NOTはREGISTER要求へのどんな応答でも、Record-ルートヘッダーフィールドの存在か欠如に基づく新しいルートセットを創設します。

   The following header fields, except Contact, MUST be included in a
   REGISTER request.  A Contact header field MAY be included:

Contactを除いて、REGISTER要求に以下のヘッダーフィールドを含まなければなりません。 Contactヘッダーフィールドは含まれるかもしれません:

      Request-URI: The Request-URI names the domain of the location
           service for which the registration is meant (for example,
           "sip:chicago.com").  The "userinfo" and "@" components of the
           SIP URI MUST NOT be present.

要求URI: Request-URIは登録が意味される位置のサービス(例えば、「一口: chicago.com」)のドメインを命名します。 一口URIの"userinfo"と"@"コンポーネントは存在しているはずがありません。

      To: The To header field contains the address of record whose
           registration is to be created, queried, or modified.  The To
           header field and the Request-URI field typically differ, as
           the former contains a user name.  This address-of-record MUST
           be a SIP URI or SIPS URI.

To: Toヘッダーフィールドは作成されるか、質問されるか、または変更される登録がことである記録されている住所を含んでいます。 前者がユーザ名を含むとき、ToヘッダーフィールドとRequest-URI分野は通常異なります。 この記録されている住所は、SIP URIかSIPS URIであるに違いありません。

Rosenberg, et. al.          Standards Track                    [Page 57]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[57ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      From: The From header field contains the address-of-record of the
           person responsible for the registration.  The value is the
           same as the To header field unless the request is a third-
           party registration.

From: Fromヘッダーフィールドは登録に責任がある人の記録されている住所を含んでいます。 値は要求が3番目のパーティー登録でないならToヘッダーフィールドと同じです。

      Call-ID: All registrations from a UAC SHOULD use the same Call-ID
           header field value for registrations sent to a particular
           registrar.

呼び出しID: UAC SHOULDからのすべての登録証明書が特定の記録係に送られた登録証明書に同じCall-IDヘッダーフィールド価値を使用します。

           If the same client were to use different Call-ID values, a
           registrar could not detect whether a delayed REGISTER request
           might have arrived out of order.

同じクライアントが異なったCall-ID値を使用するなら、記録係は、遅れたREGISTER要求が故障していた状態で到着したかもしれないかどうか検出できないでしょうに。

      CSeq: The CSeq value guarantees proper ordering of REGISTER
           requests.  A UA MUST increment the CSeq value by one for each
           REGISTER request with the same Call-ID.

CSeq: CSeq値はREGISTER要求の適切な注文を保証します。 UaはCSeq値を同じCall-IDとのそれぞれのREGISTER要求あたり1つ増加しなければなりません。

      Contact: REGISTER requests MAY contain a Contact header field with
           zero or more values containing address bindings.

接触: ゼロがあるContactヘッダーフィールドを含むかもしれないか、または以上が含有を評価するというREGISTER要求は結合を記述します。

   UAs MUST NOT send a new registration (that is, containing new Contact
   header field values, as opposed to a retransmission) until they have
   received a final response from the registrar for the previous one or
   the previous REGISTER request has timed out.

前のもののための記録係から最終的な応答を受けたか、または前のREGISTER要求は外で時間があるまで、UAsが新規登録(すなわち、「再-トランスミッション」と対照的に新しいContactヘッダーフィールド値を含んでいる)を送ってはいけません。

Rosenberg, et. al.          Standards Track                    [Page 58]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[58ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

                                                 bob
                                               +----+
                                               | UA |
                                               |    |
                                               +----+
                                                  |
                                                  |3)INVITE
                                                  |   carol@chicago.com
         chicago.com        +--------+            V
         +---------+ 2)Store|Location|4)Query +-----+
         |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
         +---------+        +--------+=======>+-----+
               A                      5)Resp      |
               |                                  |
               |                                  |
     1)REGISTER|                                  |
               |                                  |
            +----+                                |
            | UA |<-------------------------------+
   cube2214a|    |                            6)INVITE
            +----+                    carol@cube2214a.chicago.com
             carol

ボブ+----+ | Ua| | | +----+ | |3) 招待| carol@chicago.com chicago.com+--------+ +に対して---------+ 2)ストア|位置|4) 質問+-----+ |記録係|=======>| サービス|<====|プロキシ|sip.chicago.com+---------+ +--------+=======>+-----+ 5)Resp| | | | | 1)に、登録してください。| | | | +----+ | | Ua|<-------------------------------+ cube2214a| | 6) +を招待してください。----+ carol@cube2214a.chicago.com キャロル

                      Figure 2: REGISTER example

図2: REGISTERの例

      The following Contact header parameters have a special meaning in
           REGISTER requests:

以下のContactヘッダーパラメタはREGISTER要求で格別の意味があります:

      action: The "action" parameter from RFC 2543 has been deprecated.
           UACs SHOULD NOT use the "action" parameter.

動作: RFC2543からの「動作」パラメタは非難されました。 UACs SHOULDは「動作」パラメタを使用しません。

      expires: The "expires" parameter indicates how long the UA would
           like the binding to be valid.  The value is a number
           indicating seconds.  If this parameter is not provided, the
           value of the Expires header field is used instead.
           Implementations MAY treat values larger than 2**32-1
           (4294967295 seconds or 136 years) as equivalent to 2**32-1.
           Malformed values SHOULD be treated as equivalent to 3600.

期限が切れます: 「期限が切れ」パラメタは、結合がどれくらい長い間UAが有効になりたいかを示します。 値は秒を示す数です。 このパラメタが提供されないなら、Expiresヘッダーフィールドの値は代わりに使用されます。 実現は2**32-1に同じくらい同等な2**32-1(4294967295秒か136年)より大きい値を扱うかもしれません。 奇形、3600と同等物として扱われた状態でSHOULDを評価します。

10.2.1 Adding Bindings

10.2.1 結合を加えること。

   The REGISTER request sent to a registrar includes the contact
   address(es) to which SIP requests for the address-of-record should be
   forwarded.  The address-of-record is included in the To header field
   of the REGISTER request.

記録係に送られたREGISTER要求は記録されている住所を求めるSIP要求が転送されるべきである連絡先(es)を含んでいます。 記録されている住所はREGISTER要求のToヘッダーフィールドに含まれています。

Rosenberg, et. al.          Standards Track                    [Page 59]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[59ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The Contact header field values of the request typically consist of
   SIP or SIPS URIs that identify particular SIP endpoints (for example,
   "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.
   A SIP UA can choose to register telephone numbers (with the tel URL,
   RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
   as Contacts for an address-of-record, for example.

要求のContactヘッダーフィールド値は特定のSIP終点(例えば、「一口: carol@cube2214a.chicago.com 」)を特定するSIPかSIPS URIから通常成りますが、それらはどんなURI計画も使用するかもしれません。 SIP UAが、電話番号を示すのを選ぶことができる、(tel URL、RFC2806[9])またはEメールアドレス、(mailto URL、例えば、記録されている住所のためのContactsとしてのRFC2368[32])

   For example, Carol, with address-of-record "sip:carol@chicago.com",
   would register with the SIP registrar of the domain chicago.com.  Her
   registrations would then be used by a proxy server in the chicago.com
   domain to route requests for Carol's address-of-record to her SIP
   endpoint.

例えば、記録されている住所「一口: carol@chicago.com 」で、キャロルはドメインchicago.comのSIP記録係とともに記名するでしょう。 そして、彼女の登録証明書はchicago.comドメインのプロキシサーバによって使用されて、キャロルの記録されている住所を求める要求を彼女のSIP終点に発送するでしょう。

   Once a client has established bindings at a registrar, it MAY send
   subsequent registrations containing new bindings or modifications to
   existing bindings as necessary.  The 2xx response to the REGISTER
   request will contain, in a Contact header field, a complete list of
   bindings that have been registered for this address-of-record at this
   registrar.

クライアントが記録係でいったん結合を確立すると、それは必要に応じて新しい結合か既存の結合への変更を含むその後の登録証明書を送るかもしれません。 REGISTER要求への2xx応答はContactヘッダーフィールドにこの記録されている住所のためにこの記録係に登録された結合に関する全リストを含むでしょう。

   If the address-of-record in the To header field of a REGISTER request
   is a SIPS URI, then any Contact header field values in the request
   SHOULD also be SIPS URIs.  Clients should only register non-SIPS URIs
   under a SIPS address-of-record when the security of the resource
   represented by the contact address is guaranteed by other means.
   This may be applicable to URIs that invoke protocols other than SIP,
   or SIP devices secured by protocols other than TLS.

REGISTER要求のToヘッダーフィールドにおける記録されている住所がSIPS URIであるなら、どんなContactヘッダーフィールドもSIPSがURIであったなら要求でSHOULDも評価します。 連絡先によって表されたリソースのセキュリティが他の手段で保証されるときだけ、クライアントはSIPS記録されている住所の下で非SIPS URIを登録するべきです。 これはSIPを除いて、プロトコルを呼び出すか、またはTLSを除いて、プロトコルによって固定されたSIP装置を呼び出すURIに適切であるかもしれません。

   Registrations do not need to update all bindings.  Typically, a UA
   only updates its own contact addresses.

登録証明書はすべての結合をアップデートする必要はありません。 通常、UAはそれ自身の連絡先をアップデートするだけです。

10.2.1.1 Setting the Expiration Interval of Contact Addresses

10.2.1.1 連絡先の満了間隔を設定すること。

   When a client sends a REGISTER request, it MAY suggest an expiration
   interval that indicates how long the client would like the
   registration to be valid.  (As described in Section 10.3, the
   registrar selects the actual time interval based on its local
   policy.)

クライアントがREGISTER要求を送るとき、それは登録がどれくらい長い間クライアントが有効になりたいかを示す満了間隔を示すかもしれません。 (セクション10.3で説明されるように、記録係はローカルの方針に基づく実際の時間間隔を選択します。)

   There are two ways in which a client can suggest an expiration
   interval for a binding: through an Expires header field or an
   "expires" Contact header parameter.  The latter allows expiration
   intervals to be suggested on a per-binding basis when more than one
   binding is given in a single REGISTER request, whereas the former
   suggests an expiration interval for all Contact header field values
   that do not contain the "expires" parameter.

クライアントが結合のために満了間隔を勧めることができる2つの方法があります: Expiresヘッダーフィールドか「期限が切れ」Contactヘッダーパラメタを通して。 ただ一つのREGISTER要求で1つ以上の結合を与えるとき、後者は、満了間隔が1結合あたり1個のベースに示されるのを許容しますが、前者は「期限が切れ」パラメタを含まないすべてのContactヘッダーフィールド値のために満了間隔を示します。

Rosenberg, et. al.          Standards Track                    [Page 60]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[60ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   If neither mechanism for expressing a suggested expiration time is
   present in a REGISTER, the client is indicating its desire for the
   server to choose.

提案された満了時間を表すためのどちらのメカニズムもREGISTERに存在していないなら、クライアントはサーバが選ばれる願望を示しています。

10.2.1.2 Preferences among Contact Addresses

10.2.1.2 連絡先の中の好み

   If more than one Contact is sent in a REGISTER request, the
   registering UA intends to associate all of the URIs in these Contact
   header field values with the address-of-record present in the To
   field.  This list can be prioritized with the "q" parameter in the
   Contact header field.  The "q" parameter indicates a relative
   preference for the particular Contact header field value compared to
   other bindings for this address-of-record.  Section 16.6 describes
   how a proxy server uses this preference indication.

REGISTER要求で1Contactを送るなら、記録されている住所が存在していた状態で、登録しているUAはTo分野でこれらのContactヘッダーフィールド値におけるURIのすべてを関連づけるつもりです。 このリストはContactヘッダーフィールドにおける「q」パラメタで最優先することができます。 この記録されている住所のための他の結合と比べて、「q」パラメタは特定のContactヘッダーフィールド価値のための相対的選好を示します。 セクション16.6はプロキシサーバがどうこの好みの指示を使用するかを説明します。

10.2.2 Removing Bindings

10.2.2 結合を取り除くこと。

   Registrations are soft state and expire unless refreshed, but can
   also be explicitly removed.  A client can attempt to influence the
   expiration interval selected by the registrar as described in Section
   10.2.1.  A UA requests the immediate removal of a binding by
   specifying an expiration interval of "0" for that contact address in
   a REGISTER request.  UAs SHOULD support this mechanism so that
   bindings can be removed before their expiration interval has passed.

登録証明書を軟性国家であり、リフレッシュされない場合期限が切れますが、また、明らかに取り除くことができます。 クライアントは、セクション10.2.1で説明されるように記録係によって選択された満了間隔に影響を及ぼすのを試みることができます。 UAは、「レジスタ要求におけるその連絡先のための0インチ」の満了間隔を指定することによって、結合の即座の取り外しを要求します。 UAs SHOULDは、彼らの満了間隔が過ぎる前に結合を取り除くことができるようにこのメカニズムをサポートします。

   The REGISTER-specific Contact header field value of "*" applies to
   all registrations, but it MUST NOT be used unless the Expires header
   field is present with a value of "0".

「*」のREGISTER特有のContactヘッダーフィールド価値がすべての登録証明書に適用されますが、それを使用してはいけない、期限が切れる、ヘッダーフィールドは「0インチ」の値について存在しています。

      Use of the "*" Contact header field value allows a registering UA
      to remove all bindings associated with an address-of-record
      without knowing their precise values.

「*」接触ヘッダーフィールド価値の使用で、登録Uaはそれらの正確な値を知らないで記録されている住所に関連しているすべての結合を取り除くことができます。

10.2.3 Fetching Bindings

10.2.3 魅惑的な結合

   A success response to any REGISTER request contains the complete list
   of existing bindings, regardless of whether the request contained a
   Contact header field.  If no Contact header field is present in a
   REGISTER request, the list of bindings is left unchanged.

どんなREGISTER要求への成功応答も既存の結合に関する全リストを含んでいます、要求がContactヘッダーフィールドを含んだかどうかにかかわらず。 どんなContactヘッダーフィールドもREGISTER要求に存在していないなら、結合のリストは変わりがないままにされます。

10.2.4 Refreshing Bindings

10.2.4 壮快な結合

   Each UA is responsible for refreshing the bindings that it has
   previously established.  A UA SHOULD NOT refresh bindings set up by
   other UAs.

それぞれのUAはそれが以前に確立した結合をリフレッシュするのに責任があります。 UA SHOULD NOTは他のUAsによってセットアップされた結合をリフレッシュします。

Rosenberg, et. al.          Standards Track                    [Page 61]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[61ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The 200 (OK) response from the registrar contains a list of Contact
   fields enumerating all current bindings.  The UA compares each
   contact address to see if it created the contact address, using
   comparison rules in Section 19.1.4.  If so, it updates the expiration
   time interval according to the expires parameter or, if absent, the
   Expires field value.  The UA then issues a REGISTER request for each
   of its bindings before the expiration interval has elapsed.  It MAY
   combine several updates into one REGISTER request.

記録係からの200(OK)応答はすべての現在の結合を列挙するContact分野のリストを含んでいます。 UAは、セクション19.1.4に比較規則を使用して、それが連絡先を作成したかどうか確認するために各連絡先を比較します。 そうだとすれば、満了時間間隔をアップデートする、パラメタか休むときのExpires分野価値を吐き出します。 そして、満了間隔が経過する前にUAはそれぞれの結合を求めるREGISTER要求を出します。 それはREGISTERが要求する1つにいくつかのアップデートを結合するかもしれません。

   A UA SHOULD use the same Call-ID for all registrations during a
   single boot cycle.  Registration refreshes SHOULD be sent to the same
   network address as the original registration, unless redirected.

UA SHOULDはすべての登録証明書に1ブーツサイクルの間、同じCall-IDを使用します。 登録はSHOULDをリフレッシュします。オリジナルの登録向け直さない場合、同じネットワーク・アドレスに送ってください。

10.2.5 Setting the Internal Clock

10.2.5 内部クロックを設定すること。

   If the response for a REGISTER request contains a Date header field,
   the client MAY use this header field to learn the current time in
   order to set any internal clocks.

REGISTER要求のための応答がDateヘッダーフィールドを含んでいるなら、クライアントは、どんな内部クロックも設定するために現在の時間を学ぶのにこのヘッダーフィールドを使用するかもしれません。

10.2.6 Discovering a Registrar

10.2.6 記録係を発見すること。

   UAs can use three ways to determine the address to which to send
   registrations:  by configuration, using the address-of-record, and
   multicast.  A UA can be configured, in ways beyond the scope of this
   specification, with a registrar address.  If there is no configured
   registrar address, the UA SHOULD use the host part of the address-
   of-record as the Request-URI and address the request there, using the
   normal SIP server location mechanisms [4].  For example, the UA for
   the user "sip:carol@chicago.com" addresses the REGISTER request to
   "sip:chicago.com".

UAsは登録証明書を送るアドレスを決定する3つの方法を使用できます: 記録されている住所、およびマルチキャストを使用する構成で。 記録係アドレスはこの仕様の範囲を超えた方法でUAを構成できます。 構成された記録係アドレスが全くなければ、UA SHOULDはRequest-URIとして記録のアドレスのホスト部分を使用して、そこに要求を記述します、正常なSIPサーバ位置のメカニズム[4]を使用して。 例えば、ユーザ「一口: carol@chicago.com 」のためのUAは「一口: chicago.com」にREGISTER要求を記述します。

   Finally, a UA can be configured to use multicast.  Multicast
   registrations are addressed to the well-known "all SIP servers"
   multicast address "sip.mcast.net" (224.0.1.75 for IPv4).  No well-
   known IPv6 multicast address has been allocated; such an allocation
   will be documented separately when needed.  SIP UAs MAY listen to
   that address and use it to become aware of the location of other
   local users (see [33]); however, they do not respond to the request.

最終的に、マルチキャストを使用するためにUAを構成できます。 マルチキャスト登録証明書が周知の「SIPサーバ」マルチキャストアドレス"sip.mcast.net"に記述される、(224.0、.1、IPv4のための.75) よく知られているIPv6マルチキャストアドレスを全く割り当てていません。 必要であると、そのような配分は別々に記録されるでしょう。 SIP UAsは、他の地元のユーザの位置を意識するようになるのにそのアドレスを聞いて、それを使用するかもしれません。([33])を見てください。 しかしながら、彼らは要求に応じません。

      Multicast registration may be inappropriate in some environments,
      for example, if multiple businesses share the same local area
      network.

例えば、複数のビジネスが同じローカル・エリア・ネットワークを共有するなら、マルチキャスト登録はいくつかの環境で不適当であるかもしれません。

10.2.7 Transmitting a Request

10.2.7 要求を伝えること。

   Once the REGISTER method has been constructed, and the destination of
   the message identified, UACs follow the procedures described in
   Section 8.1.2 to hand off the REGISTER to the transaction layer.

REGISTER方法がいったん組み立てられて特定されたメッセージの目的地になると、UACsはセクション8.1.2で取引へのREGISTERが層にするハンドオフに説明された手順に従います。

Rosenberg, et. al.          Standards Track                    [Page 62]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[62ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   If the transaction layer returns a timeout error because the REGISTER
   yielded no response, the UAC SHOULD NOT immediately re-attempt a
   registration to the same registrar.

REGISTERが応答を全くもたらさなかったので取引層がタイムアウト誤りを返すなら、UAC SHOULD NOTはすぐに、同じ記録係に登録を再試みます。

      An immediate re-attempt is likely to also timeout.  Waiting some
      reasonable time interval for the conditions causing the timeout to
      be corrected reduces unnecessary load on the network.  No specific
      interval is mandated.

即座の再試みはタイムアウトにもありそうです。 いくつかの妥当な時間間隔に修正されるのをタイムアウトを引き起こす状態を待つと、不要な負荷はネットワークで減少します。 どんな特定の間隔も強制されません。

10.2.8 Error Responses

10.2.8 誤り応答

   If a UA receives a 423 (Interval Too Brief) response, it MAY retry
   the registration after making the expiration interval of all contact
   addresses in the REGISTER request equal to or greater than the
   expiration interval within the Min-Expires header field of the 423
   (Interval Too Brief) response.

UAが423(間隔Too Brief)応答を受けるなら、REGISTERのアドレスが要求するすべての接触の満了間隔を中では、満了間隔より等しいかすばらしくした後に登録を再試行するかもしれない、423(間隔Too Brief)応答のヘッダーフィールドをMin吐き出します。

10.3 Processing REGISTER Requests

10.3 処理レジスタ要求

   A registrar is a UAS that responds to REGISTER requests and maintains
   a list of bindings that are accessible to proxy servers and redirect
   servers within its administrative domain.  A registrar handles
   requests according to Section 8.2 and Section 17.2, but it accepts
   only REGISTER requests.  A registrar MUST not generate 6xx responses.

記録係はREGISTER要求に応じて、プロキシサーバにアクセスしやすく、管理ドメインの中でサーバを向け直す結合のリストを維持するUASです。 セクション8.2とセクション17.2によると、記録係は要求を扱いますが、それはREGISTER要求だけを受け入れます。 記録係は6xx応答を発生させてはいけません。

   A registrar MAY redirect REGISTER requests as appropriate.  One
   common usage would be for a registrar listening on a multicast
   interface to redirect multicast REGISTER requests to its own unicast
   interface with a 302 (Moved Temporarily) response.

記録係は適宜REGISTER要求を向け直すかもしれません。 1つの一般的な用法が302(Temporarilyを動かす)応答とのそれ自身のユニキャストインタフェースにマルチキャストREGISTER要求を向け直すためにマルチキャストインタフェースで聴いている記録係のためのものでしょう。

   Registrars MUST ignore the Record-Route header field if it is
   included in a REGISTER request.  Registrars MUST NOT include a
   Record-Route header field in any response to a REGISTER request.

それがREGISTER要求に含まれているなら、記録係はRecord-ルートヘッダーフィールドを無視しなければなりません。 記録係はREGISTER要求へのどんな応答でもRecord-ルートヘッダーフィールドを入れてはいけません。

      A registrar might receive a request that traversed a proxy which
      treats REGISTER as an unknown request and which added a Record-
      Route header field value.

記録係はプロキシを横断した要求を受け取るかもしれません(未知の要求としてREGISTERを扱って、Recordルートヘッダーフィールド価値を高めました)。

   A registrar has to know (for example, through configuration) the set
   of domain(s) for which it maintains bindings.  REGISTER requests MUST
   be processed by a registrar in the order that they are received.
   REGISTER requests MUST also be processed atomically, meaning that a
   particular REGISTER request is either processed completely or not at
   all.  Each REGISTER message MUST be processed independently of any
   other registration or binding changes.

記録係はそれが結合を維持するドメインのセットを知らなければなりません(例えば構成を通して)。 記録係はオーダーでREGISTER要求を処理しなければなりません。受け取ります。 また、原子論的にREGISTER要求を処理しなければなりません、特定のREGISTERが完全か全く処理されないよう要求する意味。 いかなる他の登録か拘束力がある変化の如何にかかわらずそれぞれのREGISTERメッセージを処理しなければなりません。

Rosenberg, et. al.          Standards Track                    [Page 63]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[63ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   When receiving a REGISTER request, a registrar follows these steps:

REGISTER要求を受け取るとき、記録係はこれらの方法に従います:

      1. The registrar inspects the Request-URI to determine whether it
         has access to bindings for the domain identified in the
         Request-URI.  If not, and if the server also acts as a proxy
         server, the server SHOULD forward the request to the addressed
         domain, following the general behavior for proxying messages
         described in Section 16.

1. 記録係は、それがRequest-URIで特定されたドメインのための結合に近づく手段を持っているかどうか決定するためにRequest-URIを点検します。 そうでなければ、また、サーバがプロキシサーバとして機能するなら、サーバSHOULDは記述されたドメインに要求を転送します、セクション16で説明されたメッセージをproxyingするための一般的な振舞いに続いて。

      2. To guarantee that the registrar supports any necessary
         extensions, the registrar MUST process the Require header field
         values as described for UASs in Section 8.2.2.

2. 記録係がどんな必要な拡大も支持するのを保証するために、記録係はセクション8.2.2におけるUASsのために説明されるようにRequireヘッダーフィールド値を処理しなければなりません。

      3. A registrar SHOULD authenticate the UAC.  Mechanisms for the
         authentication of SIP user agents are described in Section 22.
         Registration behavior in no way overrides the generic
         authentication framework for SIP.  If no authentication
         mechanism is available, the registrar MAY take the From address
         as the asserted identity of the originator of the request.

3. 記録係SHOULDはUACを認証します。 SIPユーザエージェントの認証のためのメカニズムはセクション22で説明されます。 登録の振舞いはSIPのために一般的な認証枠組みを決してくつがえしません。 どんな認証機構も利用可能でないなら、記録係は要求の創始者の断言されたアイデンティティとしてFromアドレスをみなすかもしれません。

      4. The registrar SHOULD determine if the authenticated user is
         authorized to modify registrations for this address-of-record.
         For example, a registrar might consult an authorization
         database that maps user names to a list of addresses-of-record
         for which that user has authorization to modify bindings.  If
         the authenticated user is not authorized to modify bindings,
         the registrar MUST return a 403 (Forbidden) and skip the
         remaining steps.

4. 記録係SHOULDは、認証されたユーザがこの記録されている住所のための登録証明書を変更するのに権限を与えられるかどうか決定します。 例えば、記録係は結合を変更するためにそのユーザが認可を持っている記録のアドレスのリストへのユーザ名を写像する認可データベースに相談するかもしれません。 認証されたユーザが結合を変更するのに権限を与えられないなら、記録係は、403(禁じられる)を返して、残っているステップをサボらなければなりません。

         In architectures that support third-party registration, one
         entity may be responsible for updating the registrations
         associated with multiple addresses-of-record.

第三者登録を支持する構造では、1つの実体が記録の複数のアドレスに関連している登録証明書をアップデートするのに原因となるかもしれません。

      5. The registrar extracts the address-of-record from the To header
         field of the request.  If the address-of-record is not valid
         for the domain in the Request-URI, the registrar MUST send a
         404 (Not Found) response and skip the remaining steps.  The URI
         MUST then be converted to a canonical form.  To do that, all
         URI parameters MUST be removed (including the user-param), and
         any escaped characters MUST be converted to their unescaped
         form.  The result serves as an index into the list of bindings.

5. 記録係は要求のToヘッダーフィールドから記録されている住所を抜粋します。 Request-URIにおけるドメインには、記録されている住所が有効でないなら、記録係は、404(Foundでない)応答を送って、残っているステップをサボらなければなりません。 そして、URIを標準形に変換しなければなりません。 それをするために、すべてのURIパラメタを取り除かなければなりません、そして、(ユーザ-paramを含んでいます)どんな逃げられたキャラクタも彼らの非エスケープしているフォームに変換しなければなりません。 結果はインデックスとして結合のリストの中に機能します。

Rosenberg, et. al.          Standards Track                    [Page 64]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[64ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      6. The registrar checks whether the request contains the Contact
         header field.  If not, it skips to the last step.  If the
         Contact header field is present, the registrar checks if there
         is one Contact field value that contains the special value "*"
         and an Expires field.  If the request has additional Contact
         fields or an expiration time other than zero, the request is
         invalid, and the server MUST return a 400 (Invalid Request) and
         skip the remaining steps.  If not, the registrar checks whether
         the Call-ID agrees with the value stored for each binding.  If
         not, it MUST remove the binding.  If it does agree, it MUST
         remove the binding only if the CSeq in the request is higher
         than the value stored for that binding.  Otherwise, the update
         MUST be aborted and the request fails.

6. 記録係は、要求がContactヘッダーフィールドを含むかどうかチェックします。 そうでなければ、それは最後のステップまでスキップされます。 そして、Contactヘッダーフィールドが存在しているなら、記録係が、特別な値の「*」を含む1つのContact分野価値があるかどうかチェックする、野原を吐き出します。 要求に追加Contact分野かゼロ以外の満了時間があるなら、要求が無効であり、サーバは、400(無効のRequest)を返して、残っているステップをサボらなければなりません。 そうでなければ、記録係は、Call-IDが各結合のために格納された値に同意するかどうかチェックします。 そうでなければ、それは結合を取り除かなければなりません。 同意するなら、要求におけるCSeqがその結合のために格納された値より高い場合にだけ、それは結合を取り除かなければなりません。 さもなければ、アップデートを中止しなければなりません、そして、要求は失敗します。

      7. The registrar now processes each contact address in the Contact
         header field in turn.  For each address, it determines the
         expiration interval as follows:

7. 記録係は今、順番にContactヘッダーフィールドにおける各連絡先を処理します。 各アドレスのために、以下の満了間隔を決定します:

         -  If the field value has an "expires" parameter, that value
            MUST be taken as the requested expiration.

- 分野値に「期限が切れ」パラメタがあるなら、要求された満了としてその値をみなさなければなりません。

         -  If there is no such parameter, but the request has an
            Expires header field, that value MUST be taken as the
            requested expiration.

- どんなそのようなパラメタもありませんが、要求にExpiresヘッダーフィールドがあるなら、要求された満了としてその値をみなさなければなりません。

         -  If there is neither, a locally-configured default value MUST
            be taken as the requested expiration.

- どちらもなければ、要求された満了として局所的に構成されたデフォルト値をみなさなければなりません。

         The registrar MAY choose an expiration less than the requested
         expiration interval.  If and only if the requested expiration
         interval is greater than zero AND smaller than one hour AND
         less than a registrar-configured minimum, the registrar MAY
         reject the registration with a response of 423 (Interval Too
         Brief).  This response MUST contain a Min-Expires header field
         that states the minimum expiration interval the registrar is
         willing to honor.  It then skips the remaining steps.

記録係は要求された満了間隔ほど満了を選ばないかもしれません。 要求された満了間隔である場合にだけ、423(間隔Too Brief)の応答があるゼロ以上と記録係によって構成された最小限、記録係が登録を拒絶するかもしれないより少ない1時間よりわずかなANDはそうです。 この応答はaを含まなければなりません。記録係が光栄に思っても構わないと思っている最小の満了間隔を述べるヘッダーフィールドをMin吐き出します。 そして、それは残っているステップをサボります。

         Allowing the registrar to set the registration interval
         protects it against excessively frequent registration refreshes
         while limiting the state that it needs to maintain and
         decreasing the likelihood of registrations going stale.  The
         expiration interval of a registration is frequently used in the
         creation of services.  An example is a follow-me service, where
         the user may only be available at a terminal for a brief
         period.  Therefore, registrars should accept brief
         registrations; a request should only be rejected if the
         interval is so short that the refreshes would degrade registrar
         performance.

記録係が登録間隔を設定するのを許容するのがそれが維持する必要がある状態を制限している間、リフレッシュして、登録証明書が行くという見込みを減少させると聞き古したである過度に頻繁な登録に対してそれを保護します。 登録の満了間隔はサービスの作成で頻繁に費やされます。 例はユーザが端末に単に簡潔な期間に手があくかもしれないところの私に続いているサービスです。 したがって、記録係は簡潔な登録証明書を受け入れるはずです。 要求が間隔がしたがって、それをショートすることである場合にだけ拒絶されるべきである、リフレッシュ、記録係性能を下げるでしょう。

Rosenberg, et. al.          Standards Track                    [Page 65]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[65ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         For each address, the registrar then searches the list of
         current bindings using the URI comparison rules.  If the
         binding does not exist, it is tentatively added.  If the
         binding does exist, the registrar checks the Call-ID value.  If
         the Call-ID value in the existing binding differs from the
         Call-ID value in the request, the binding MUST be removed if
         the expiration time is zero and updated otherwise.  If they are
         the same, the registrar compares the CSeq value.  If the value
         is higher than that of the existing binding, it MUST update or
         remove the binding as above.  If not, the update MUST be
         aborted and the request fails.

そして、各アドレスのために、記録係は、URI比較規則を使用することで現在の結合のリストを捜します。 結合が存在していないなら、それは試験的に加えられます。 結合が存在しているなら、記録係はCall-ID値をチェックします。 既存の結合におけるCall-ID値が要求におけるCall-ID値と異なっているなら、満了時間がゼロであり、別の方法でアップデートして、結合を取り除かなければなりません。 それらが同じであるなら、記録係はCSeq値を比較します。 値が既存の結合のものより高いなら、それは、上の結合をアップデートしなければならないか、または取り除かなければなりません。 そうでなければ、アップデートを中止しなければなりません、そして、要求は失敗します。

         This algorithm ensures that out-of-order requests from the same
         UA are ignored.

このアルゴリズムは、同じUAからの不適切な要求が無視されるのを確実にします。

         Each binding record records the Call-ID and CSeq values from
         the request.

それぞれの拘束力がある記録は要求からCall-IDとCSeq値を記録します。

         The binding updates MUST be committed (that is, made visible to
         the proxy or redirect server) if and only if all binding
         updates and additions succeed.  If any one of them fails (for
         example, because the back-end database commit failed), the
         request MUST fail with a 500 (Server Error) response and all
         tentative binding updates MUST be removed.

そして、拘束力があるアップデートを遂行しなければならない、(すなわち、プロキシか再直接のサーバに目に見えるのに作られています)すべて付く場合にだけ、アップデートと追加は成功します。 それらのどれかが失敗するなら(バックエンドデータベースが例えば失敗されていた状態で公約するので)、500(サーバError)応答に応じて、要求は失敗しなければなりません、そして、すべての一時的な拘束力があるアップデートを取り除かなければなりません。

      8. The registrar returns a 200 (OK) response.  The response MUST
         contain Contact header field values enumerating all current
         bindings.  Each Contact value MUST feature an "expires"
         parameter indicating its expiration interval chosen by the
         registrar.  The response SHOULD include a Date header field.

8. 記録係は200(OK)応答を返します。 応答はすべての現在の結合を列挙するContactヘッダーフィールド値を含まなければなりません。 それぞれのContact値は記録係によって選ばれた満了間隔を示す「期限が切れ」パラメタを特徴としなければなりません。 応答SHOULDはDateヘッダーフィールドを含んでいます。

11 Querying for Capabilities

11 能力のための質問

   The SIP method OPTIONS allows a UA to query another UA or a proxy
   server as to its capabilities.  This allows a client to discover
   information about the supported methods, content types, extensions,
   codecs, etc. without "ringing" the other party.  For example, before
   a client inserts a Require header field into an INVITE listing an
   option that it is not certain the destination UAS supports, the
   client can query the destination UAS with an OPTIONS to see if this
   option is returned in a Supported header field.  All UAs MUST support
   the OPTIONS method.

SIPメソッドOPTIONSはUAに能力に関して別のUAかプロキシサーバについて質問させます。 これで、相手が「鳴らす」でなくて、クライアントはサポートしているメソッド、content type、拡大、コーデックなどの情報を発見できます。 例えば、以前、クライアントはSupportedヘッダーフィールドでこのオプションを返すなら見るのがOPTIONSと共にUASがサポートする目的地であり、クライアントが目的地UASについて質問できるのを確信していないオプションを記載するINVITEにRequireヘッダーフィールドを挿入します。 すべてのUAsが、OPTIONSがメソッドであるとサポートしなければなりません。

   The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.  If the OPTIONS is
   addressed to a proxy server, the Request-URI is set without a user
   part, similar to the way a Request-URI is set for a REGISTER request.

OPTIONS要求の目標はRequest-URIによって特定されます。(URIは別のUAかSIPサーバを特定できました)。OPTIONSがプロキシサーバに扱われるなら、Request-URIはユーザ部分なしで設定されます、Request-URIがREGISTER要求に設定される方法と同様です。

Rosenberg, et. al.          Standards Track                    [Page 66]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[66ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Alternatively, a server receiving an OPTIONS request with a Max-
   Forwards header field value of 0 MAY respond to the request
   regardless of the Request-URI.

あるいはまた、マックスが前方にいる0のOPTIONS要求ヘッダーフィールド価値を受けるサーバはRequest-URIにかかわらず要求に応じるかもしれません。

      This behavior is common with HTTP/1.1.  This behavior can be used
      as a "traceroute" functionality to check the capabilities of
      individual hop servers by sending a series of OPTIONS requests
      with incremented Max-Forwards values.

この振舞いはHTTP/1.1について一般的です。 一連のOPTIONS要求を送ることによって増加している前方へマックス値に個々のホップサーバの能力について問い合わせるのに「トレースルート」の機能性としてこの振舞いを使用できます。

   As is the case for general UA behavior, the transaction layer can
   return a timeout error if the OPTIONS yields no response.  This may
   indicate that the target is unreachable and hence unavailable.

一般的なUAの振舞いのためのケースのように、OPTIONSが応答を全くもたらさないなら、トランザクション層はタイムアウト誤りを返すことができます。 これは、目標が手が届かなくて、したがって、入手できないのを示すかもしれません。

   An OPTIONS request MAY be sent as part of an established dialog to
   query the peer on capabilities that may be utilized later in the
   dialog.

後で対話で利用されるかもしれない能力で同輩について質問するために確立した対話の一部としてOPTIONS要求を送るかもしれません。

11.1 Construction of OPTIONS Request

11.1 オプション要求の工事

   An OPTIONS request is constructed using the standard rules for a SIP
   request as discussed in Section 8.1.1.

OPTIONS要求は、SIP要求にセクション8.1.1で議論するように標準の規則を使用することで構成されます。

   A Contact header field MAY be present in an OPTIONS.

ContactヘッダーフィールドはOPTIONSに存在しているかもしれません。

   An Accept header field SHOULD be included to indicate the type of
   message body the UAC wishes to receive in the response.  Typically,
   this is set to a format that is used to describe the media
   capabilities of a UA, such as SDP (application/sdp).

UACが応答で受けたがっているメッセージ本体のタイプを示すために含まれていて、AcceptヘッダーはSHOULDをさばきます。 通常、これはUAのメディア能力について説明するのに使用される形式に設定されます、SDP(アプリケーション/sdp)などのように。

   The response to an OPTIONS request is assumed to be scoped to the
   Request-URI in the original request.  However, only when an OPTIONS
   is sent as part of an established dialog is it guaranteed that future
   requests will be received by the server that generated the OPTIONS
   response.

OPTIONS要求への応答によってオリジナルの要求におけるRequest-URIに見られると思われます。 しかしながら、確立した対話の一部がそれであるのでいつだけOPTIONSを送るかは、今後の要求がOPTIONSが応答であると生成したサーバによって受け取られるのを保証しました。

   Example OPTIONS request:

例のOPTIONSは以下を要求します。

      OPTIONS sip:carol@chicago.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
      Max-Forwards: 70
      To: <sip:carol@chicago.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:alice@pc33.atlanta.com>
      Accept: application/sdp
      Content-Length: 0

OPTIONS一口: carol@chicago.com SIP/2.0Via: 一口/2.0/UDP pc33.atlanta.com; ブランチは前方へz9hG4bKhjhs8ass877マックスと等しいです: 70 To: <一口: carol@chicago.com 、gt;、From: アリス<一口: alice@atlanta.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 63104のオプションが以下に連絡します。 <一口: alice@pc33.atlanta.com 、gt;、受け入れます: sdp Contentアプリケーション/長さ: 0

Rosenberg, et. al.          Standards Track                    [Page 67]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[67ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

11.2 Processing of OPTIONS Request

11.2 オプション要求の処理

   The response to an OPTIONS is constructed using the standard rules
   for a SIP response as discussed in Section 8.2.6.  The response code
   chosen MUST be the same that would have been chosen had the request
   been an INVITE.  That is, a 200 (OK) would be returned if the UAS is
   ready to accept a call, a 486 (Busy Here) would be returned if the
   UAS is busy, etc.  This allows an OPTIONS request to be used to
   determine the basic state of a UAS, which can be an indication of
   whether the UAS will accept an INVITE request.

OPTIONSへの応答は、SIP応答にセクション8.2.6で議論するように標準の規則を使用することで構成されます。 要求があったなら選ばれた同じくらいがINVITEであったに違いないなら選ばれた応答コード。 UASが呼び出しを受け入れる準備ができているなら、すなわち、200(OK)を返して、UASが忙しいのなどなら、486(忙しいHere)を返すでしょう。 これはUASがINVITE要求を受け入れるかどうかしるしであるかもしれないUASの基本的な州を決定するのに使用されるというOPTIONS要求を許します。

   An OPTIONS request received within a dialog generates a 200 (OK)
   response that is identical to one constructed outside a dialog and
   does not have any impact on the dialog.

対話の中に受け取られたOPTIONS要求は、対話の外で構成された1つと同じ200(OK)応答を生成して、対話にどんな影響力も持っていません。

   This use of OPTIONS has limitations due to the differences in proxy
   handling of OPTIONS and INVITE requests.  While a forked INVITE can
   result in multiple 200 (OK) responses being returned, a forked
   OPTIONS will only result in a single 200 (OK) response, since it is
   treated by proxies using the non-INVITE handling.  See Section 16.7
   for the normative details.

OPTIONSのこの使用には、OPTIONSとINVITE要求のプロキシ取り扱いの違いによる制限があります。 股状のINVITEが返される複数の200(OK)の応答をもたらすことができる間、股状のOPTIONSはただ一つの200(OK)応答をもたらすだけでしょう、それが非INVITE取り扱いを使用することでプロキシによって扱われるので。 標準の詳細に関してセクション16.7を見てください。

   If the response to an OPTIONS is generated by a proxy server, the
   proxy returns a 200 (OK), listing the capabilities of the server.
   The response does not contain a message body.

OPTIONSへの応答がプロキシサーバによって生成されるなら、プロキシは200(OK)を返します、サーバの能力を記載して。応答はメッセージ本体を含んでいません。

   Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
   fields SHOULD be present in a 200 (OK) response to an OPTIONS
   request.  If the response is generated by a proxy, the Allow header
   field SHOULD be omitted as it is ambiguous since a proxy is method
   agnostic.  Contact header fields MAY be present in a 200 (OK)
   response and have the same semantics as in a 3xx response.  That is,
   they may list a set of alternative names and methods of reaching the
   user.  A Warning header field MAY be present.

許容、Accept、Accept-コード化、Accept-言語、およびSupportedヘッダーは現在のコネがOPTIONS要求への200(OK)応答であったならSHOULDをさばきます。 応答がプロキシによって生成されるなら、AllowヘッダーはSHOULDをさばきます。それがあいまいであるので、プロキシがメソッド不可知論者であるときに、省略されます。 分野が3xx応答で200(OK)応答で存在していて、同じ意味論を持っているかもしれないヘッダーを連絡してください。 すなわち、彼らは1セットの代替名とユーザに届くメソッドを記載するかもしれません。 Warningヘッダーフィールドは存在しているかもしれません。

   A message body MAY be sent, the type of which is determined by the
   Accept header field in the OPTIONS request (application/sdp is the
   default if the Accept header field is not present).  If the types
   include one that can describe media capabilities, the UAS SHOULD
   include a body in the response for that purpose.  Details on the
   construction of such a body in the case of application/sdp are
   described in [13].

ボディーを送るかもしれないというメッセージ(Acceptヘッダーフィールドが存在していないなら、アプリケーション/sdpはデフォルトです)。それのタイプはOPTIONS要求におけるAcceptヘッダー分野で決定しています。 タイプがメディア能力について説明できるものを入れるなら、UAS SHOULDは応答にそのためにボディーを含んでいます。 アプリケーション/sdpの場合における、そのようなボディーの工事に関する詳細は[13]で説明されます。

Rosenberg, et. al.          Standards Track                    [Page 68]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[68ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example OPTIONS response generated by a UAS (corresponding to the
   request in Section 11.1):

UAS(セクション11.1での要求に対応する)によって生成された例のOPTIONS応答:

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
       ;received=192.0.2.4
      To: <sip:carol@chicago.com>;tag=93810874
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:carol@chicago.com>
      Contact: <mailto:carol@chicago.com>
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
      Accept: application/sdp
      Accept-Encoding: gzip
      Accept-Language: en
      Supported: foo
      Content-Type: application/sdp
      Content-Length: 274

以下を通って一口/2.0 200OK 一口/2.0/UDP pc33.atlanta.com; ブランチはz9hG4bKhjhs8ass877と等しいです; =192.0.2.4To:を受けます。 <一口: carol@chicago.com 、gt;、;=93810874From:にタグ付けをしてください アリス<一口: alice@atlanta.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 63104のオプションが以下に連絡します。 <一口: carol@chicago.com 、gt;、接触: <mailto: carol@chicago.com 、gt;、許容します: 招待、ACKは取り消して、さようならはオプション、受け入れます: sdp Acceptをアプリケーション/コード化しています: gzip Accept-言語: アンSupported: fooコンテントタイプ: sdp Contentアプリケーション/長さ: 274

      (SDP not shown)

(見せられなかったSDP)

12 Dialogs

12の対話

   A key concept for a user agent is that of a dialog.  A dialog
   represents a peer-to-peer SIP relationship between two user agents
   that persists for some time.  The dialog facilitates sequencing of
   messages between the user agents and proper routing of requests
   between both of them.  The dialog represents a context in which to
   interpret SIP messages.  Section 8 discussed method independent UA
   processing for requests and responses outside of a dialog.  This
   section discusses how those requests and responses are used to
   construct a dialog, and then how subsequent requests and responses
   are sent within a dialog.

ユーザエージェントへの重要な考えは対話のものです。 対話は2人のユーザエージェントの間のしばらく持続するピアツーピアSIP関係を表します。 対話はユーザエージェントの間のメッセージの配列とそれらの両方の間の要求の適切なルーティングを容易にします。 対話はSIPメッセージを解釈する文脈を表します。 セクション8は要求と応答のために対話の外に処理するメソッドの独立しているUAについて論じました。 このセクションは、それらの要求と応答が対話を構成するのにどのように使用されるか、そして、次に、その後の要求と応答が対話の中でどのように送られるかを論じます。

   A dialog is identified at each UA with a dialog ID, which consists of
   a Call-ID value, a local tag and a remote tag.  The dialog ID at each
   UA involved in the dialog is not the same.  Specifically, the local
   tag at one UA is identical to the remote tag at the peer UA.  The
   tags are opaque tokens that facilitate the generation of unique
   dialog IDs.

対話は各UAで対話IDで特定されます。(それは、Call-ID値、地方のタグ、およびリモートタグから成ります)。 各UAのIDが対話にかかわった対話は同じではありません。 明確に、1UAの地方のタグは同輩UAでリモートタグと同じです。 タグはユニークな対話IDの世代を容易にする不透明なトークンです。

   A dialog ID is also associated with all responses and with any
   request that contains a tag in the To field.  The rules for computing
   the dialog ID of a message depend on whether the SIP element is a UAC
   or UAS.  For a UAC, the Call-ID value of the dialog ID is set to the
   Call-ID of the message, the remote tag is set to the tag in the To
   field of the message, and the local tag is set to the tag in the From

また、対話IDもすべての応答とTo分野にタグを保管しているどんな要求にも関連しています。 メッセージの対話IDを計算するための規則はSIP要素がUACかそれともUASであるかによります。 UACにおいて、対話IDのCall-ID値はメッセージのCall-IDに設定されて、リモートタグはメッセージのTo分野のタグに設定されて、地方のタグはFromのタグに設定されます。

Rosenberg, et. al.          Standards Track                    [Page 69]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[69ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   field of the message (these rules apply to both requests and
   responses).  As one would expect for a UAS, the Call-ID value of the
   dialog ID is set to the Call-ID of the message, the remote tag is set
   to the tag in the From field of the message, and the local tag is set
   to the tag in the To field of the message.

メッセージ(これらの規則は要求と応答の両方に適用される)の分野。 人がUASのために予想するように、対話IDのCall-ID値はメッセージのCall-IDに設定されます、そして、リモートタグはメッセージのFrom分野のタグに設定されます、そして、地方のタグはメッセージのTo分野のタグに設定されます。

   A dialog contains certain pieces of state needed for further message
   transmissions within the dialog.  This state consists of the dialog
   ID, a local sequence number (used to order requests from the UA to
   its peer), a remote sequence number (used to order requests from its
   peer to the UA), a local URI, a remote URI, remote target, a boolean
   flag called "secure", and a route set, which is an ordered list of
   URIs.  The route set is the list of servers that need to be traversed
   to send a request to the peer.  A dialog can also be in the "early"
   state, which occurs when it is created with a provisional response,
   and then transition to the "confirmed" state when a 2xx final
   response arrives.  For other responses, or if no response arrives at
   all on that dialog, the early dialog terminates.

対話は対話の中でさらなるメッセージ送信に必要であった、ある状態を含んでいます。 この状態は対話ID、局所的配列番号(以前はよくUAから同輩までの要求を注文していた)、リモート一連番号(以前はよく同輩からUAまでの要求を注文していた)、地方のURI、リモートURI、リモート目標、「安全である」と呼ばれる論理演算子旗、およびルートセットから成ります。(それは、URIの規則正しいリストです)。 ルートセットは要求を同輩に送るために横断される必要があるサーバのリストです。 また、対話が「早い」状態にあることができます、そして、2xxの最終的な応答であるときに、次に「確認された」状態への変遷は到着します。(それが暫定的な応答で作成されるとき、状態は起こります)。 他の応答かそれとも応答がその対話で全く到着しないかどうかに関しては、早めの対話は終わります。

12.1 Creation of a Dialog

12.1 対話の作成

   Dialogs are created through the generation of non-failure responses
   to requests with specific methods.  Within this specification, only
   2xx and 101-199 responses with a To tag, where the request was
   INVITE, will establish a dialog.  A dialog established by a non-final
   response to a request is in the "early" state and it is called an
   early dialog.  Extensions MAY define other means for creating
   dialogs.  Section 13 gives more details that are specific to the
   INVITE method.  Here, we describe the process for creation of dialog
   state that is not dependent on the method.

対話は特定のメソッドで要求への非失敗応答の時代で作成されます。 この仕様の中では、Toタグによる2xxと101-199の応答だけが要求がINVITEであったところで対話を確立するでしょう。 要求への非最終的な応答で確立された対話が「早い」状態にあります、そして、それは早めの対話と呼ばれます。 拡大は対話を作成するための他の手段を定義するかもしれません。 セクション13はINVITEメソッドに特定のその他の詳細を与えます。 ここで、私たちはメソッドに依存しない対話状態の創設のためにプロセスについて説明します。

   UAs MUST assign values to the dialog ID components as described
   below.

UAsは以下で説明されるように対話IDコンポーネントに値を割り当てなければなりません。

12.1.1 UAS behavior

12.1.1 UASの振舞い

   When a UAS responds to a request with a response that establishes a
   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
   header field values from the request into the response (including the
   URIs, URI parameters, and any Record-Route header field parameters,
   whether they are known or unknown to the UAS) and MUST maintain the
   order of those values.  The UAS MUST add a Contact header field to
   the response.  The Contact header field contains an address where the
   UAS would like to be contacted for subsequent requests in the dialog
   (which includes the ACK for a 2xx response in the case of an INVITE).
   Generally, the host portion of this URI is the IP address or FQDN of
   the host.  The URI provided in the Contact header field MUST be a SIP
   or SIPS URI.  If the request that initiated the dialog contained a

UASが応答で要求に応じるとき、それは対話(INVITEへの2xxなどの)を確立します、すべてのRecord-ルートヘッダーフィールドが要求から応答(UASにおいて、それらが知られているか、または未知であることにかかわらずURI、URIパラメタ、およびどんなRecord-ルートヘッダーフィールドパラメタも含んでいる)に評価して、それらの値の注文であることを支持しなければならないUAS MUSTコピー。 UAS MUSTはContactヘッダーフィールドを応答に加えます。 ContactヘッダーフィールドはUASが対話(INVITEの場合における2xx応答のためのACKを含んでいる)におけるその後の要求のために連絡されたいアドレスを含んでいます。 一般に、このURIのホスト部分は、ホストのIPのアドレスかFQDNです。 Contactヘッダーフィールドに提供されたURIは、SIPかSIPS URIであるに違いありません。 対話を開始した要求がaを含んだなら

Rosenberg, et. al.          Standards Track                    [Page 70]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[70ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   SIPS URI in the Request-URI or in the top Record-Route header field
   value, if there was any, or the Contact header field if there was no
   Record-Route header field, the Contact header field in the response
   MUST be a SIPS URI.  The URI SHOULD have global scope (that is, the
   same URI can be used in messages outside this dialog).  The same way,
   the scope of the URI in the Contact header field of the INVITE is not
   limited to this dialog either.  It can therefore be used in messages
   to the UAC even outside this dialog.

Request-URIか最高Record-ルートヘッダーフィールド価値におけるSIPS URI、いずれかあったか、そこであるならContactヘッダーフィールドがRecord-ルートヘッダーフィールドでなかったなら、応答におけるContactヘッダーフィールドはSIPS URIであるに違いありません。 URI SHOULDには、グローバルな範囲があります(メッセージでこの対話の外にすなわち、同じURIを使用できます)。 同じように、INVITEのContactヘッダーフィールドにおけるURIの範囲はこの対話に制限されません。 したがって、UACへのメッセージでこの対話の外にさえそれを使用できます。

   The UAS then constructs the state of the dialog.  This state MUST be
   maintained for the duration of the dialog.

そして、UASは対話の状態を構成します。 対話の持続時間のためにこの状態を維持しなければなりません。

   If the request arrived over TLS, and the Request-URI contained a SIPS
   URI, the "secure" flag is set to TRUE.

要求がTLSの上で到着して、Request-URIがSIPS URIを含んだなら、「安全な」旗はTRUEに設定されます。

   The route set MUST be set to the list of URIs in the Record-Route
   header field from the request, taken in order and preserving all URI
   parameters.  If no Record-Route header field is present in the
   request, the route set MUST be set to the empty set.  This route set,
   even if empty, overrides any pre-existing route set for future
   requests in this dialog.  The remote target MUST be set to the URI
   from the Contact header field of the request.

ルートセットは要求からのRecord-ルートヘッダーフィールドにおけるURIのリストへのセットであるに違いありません、整然とした状態で取られて、すべてのURIパラメタを保存して。 どんなRecord-ルートヘッダーフィールドも要求に存在していないなら、ルートセットを空集合に設定しなければなりません。 空であっても設定されたこのルートはこの対話における今後の要求のためにどんな先在のルートセットもくつがえします。 要求のContactヘッダーフィールドからのURIにリモート目標を設定しなければなりません。

   The remote sequence number MUST be set to the value of the sequence
   number in the CSeq header field of the request.  The local sequence
   number MUST be empty.  The call identifier component of the dialog ID
   MUST be set to the value of the Call-ID in the request.  The local
   tag component of the dialog ID MUST be set to the tag in the To field
   in the response to the request (which always includes a tag), and the
   remote tag component of the dialog ID MUST be set to the tag from the
   From field in the request.  A UAS MUST be prepared to receive a
   request without a tag in the From field, in which case the tag is
   considered to have a value of null.

要求のCSeqヘッダーフィールドにおける、一連番号の値にリモート一連番号を設定しなければなりません。 局所的配列番号は空であるに違いありません。 要求における、Call-IDの値に対話IDの呼び出し識別子成分を設定しなければなりません。 対話IDの地方のタグの部品は要求(いつもタグを含んでいる)への応答におけるTo分野のタグへのセットであるに違いありません、そして、対話IDのリモートタグの部品は要求におけるFrom分野からのタグへのセットであるに違いありません。 UAS MUSTがFrom分野にタグなしで要求を受け取るように準備されて、その場合、タグにはヌルの値があると考えられます。

      This is to maintain backwards compatibility with RFC 2543, which
      did not mandate From tags.

これは、後方にRFC2543との互換性を維持するためのものです。(RFCはFromタグを強制しませんでした)。

   The remote URI MUST be set to the URI in the From field, and the
   local URI MUST be set to the URI in the To field.

From分野のURIにリモートURIを設定しなければなりません、そして、To分野のURIに地方のURIを設定しなければなりません。

12.1.2 UAC Behavior

12.1.2 UACの振舞い

   When a UAC sends a request that can establish a dialog (such as an
   INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
   the same SIP URI can be used in messages outside this dialog) in the
   Contact header field of the request.  If the request has a Request-
   URI or a topmost Route header field value with a SIPS URI, the
   Contact header field MUST contain a SIPS URI.

UACが対話(INVITEなどの)を確立できる要求を送るとき、それは要求のContactヘッダーフィールドでグローバルな範囲(メッセージでこの対話の外にすなわち、同じSIP URIを使用できる)をSIPかSIPS URIに提供しなければなりません。 要求にRequest URIかSIPS URIがある最上のRouteヘッダーフィールド価値があるなら、ContactヘッダーフィールドはSIPS URIを含まなければなりません。

Rosenberg, et. al.          Standards Track                    [Page 71]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[71ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   When a UAC receives a response that establishes a dialog, it
   constructs the state of the dialog.  This state MUST be maintained
   for the duration of the dialog.

UACが対話を確立する応答を受けるとき、それは対話の状態を構成します。 対話の持続時間のためにこの状態を維持しなければなりません。

   If the request was sent over TLS, and the Request-URI contained a
   SIPS URI, the "secure" flag is set to TRUE.

TLSの上に要求を送って、Request-URIがSIPS URIを含んだなら、「安全な」旗はTRUEに設定されます。

   The route set MUST be set to the list of URIs in the Record-Route
   header field from the response, taken in reverse order and preserving
   all URI parameters.  If no Record-Route header field is present in
   the response, the route set MUST be set to the empty set.  This route
   set, even if empty, overrides any pre-existing route set for future
   requests in this dialog.  The remote target MUST be set to the URI
   from the Contact header field of the response.

ルートセットは応答からのRecord-ルートヘッダーフィールドにおけるURIのリストへのセットであるに違いありません、逆順で取られて、すべてのURIパラメタを保存して。 どんなRecord-ルートヘッダーフィールドも応答で存在していないなら、ルートセットを空集合に設定しなければなりません。 空であっても設定されたこのルートはこの対話における今後の要求のためにどんな先在のルートセットもくつがえします。 応答のContactヘッダーフィールドからのURIにリモート目標を設定しなければなりません。

   The local sequence number MUST be set to the value of the sequence
   number in the CSeq header field of the request.  The remote sequence
   number MUST be empty (it is established when the remote UA sends a
   request within the dialog).  The call identifier component of the
   dialog ID MUST be set to the value of the Call-ID in the request.
   The local tag component of the dialog ID MUST be set to the tag in
   the From field in the request, and the remote tag component of the
   dialog ID MUST be set to the tag in the To field of the response.  A
   UAC MUST be prepared to receive a response without a tag in the To
   field, in which case the tag is considered to have a value of null.

要求のCSeqヘッダーフィールドにおける、一連番号の値に局所的配列番号を設定しなければなりません。 リモート一連番号は空であるに違いありません(リモートUAが対話の中で要求を送るとき、それは確立しています)。 要求における、Call-IDの値に対話IDの呼び出し識別子成分を設定しなければなりません。 対話IDの地方のタグの部品を要求におけるFrom分野のタグに設定しなければなりません、そして、対話IDのリモートタグの部品を応答のTo分野のタグに設定しなければなりません。 UAC MUSTがTo分野でタグなしで応答を受けるように準備されて、その場合、タグにはヌルの値があると考えられます。

      This is to maintain backwards compatibility with RFC 2543, which
      did not mandate To tags.

これは、後方にRFC2543との互換性を維持するためのものです。(RFCはToタグを強制しませんでした)。

   The remote URI MUST be set to the URI in the To field, and the local
   URI MUST be set to the URI in the From field.

To分野のURIにリモートURIを設定しなければなりません、そして、From分野のURIに地方のURIを設定しなければなりません。

12.2 Requests within a Dialog

12.2 対話の中の要求

   Once a dialog has been established between two UAs, either of them
   MAY initiate new transactions as needed within the dialog.  The UA
   sending the request will take the UAC role for the transaction.  The
   UA receiving the request will take the UAS role.  Note that these may
   be different roles than the UAs held during the transaction that
   established the dialog.

対話が2UAsの間でいったん確立されると、いずれか一方が必要に応じて対話の中で新しいトランザクションを開始するかもしれません。 要求を送るUAはUACの役割をトランザクションに果たすでしょう。 要求を受け取るUAはUASの役割を果たすでしょう。 これらが対話を確立したトランザクションの間に持たれていたUAsより異なる役割であるかもしれないことに注意してください。

   Requests within a dialog MAY contain Record-Route and Contact header
   fields.  However, these requests do not cause the dialog's route set
   to be modified, although they may modify the remote target URI.
   Specifically, requests that are not target refresh requests do not
   modify the dialog's remote target URI, and requests that are target
   refresh requests do.  For dialogs that have been established with an

対話の中の要求はRecord-ルートとContactヘッダーフィールドを含むかもしれません。 しかしながら、これらの要求で、対話のルートセットを変更しません、リモート目標URIを変更するかもしれませんが。 明確に、目標が要求をリフレッシュするということでない要求は対話のリモート目標URIを変更しません、そして、目標が要求をリフレッシュするということである要求はそのように変更します。 それが設立された対話

Rosenberg, et. al.          Standards Track                    [Page 72]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[72ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   INVITE, the only target refresh request defined is re-INVITE (see
   Section 14).  Other extensions may define different target refresh
   requests for dialogs established in other ways.

INVITE、唯一の目標が要求をリフレッシュします。定義されているのは、再INVITE(セクション14を見る)です。 他の拡大は定義されるかもしれません。異なった目標は他の方法で確立された対話を求める要求をリフレッシュします。

      Note that an ACK is NOT a target refresh request.

ACKが目標でないというメモは要求をリフレッシュします。

   Target refresh requests only update the dialog's remote target URI,
   and not the route set formed from the Record-Route.  Updating the
   latter would introduce severe backwards compatibility problems with
   RFC 2543-compliant systems.

目標はルートではなく、対話のリモート目標URIが設定するアップデートだけがRecord-ルートから形成されたという要求をリフレッシュします。 後者をアップデートすると、RFCの2543年の対応することのシステムの厳しい遅れている互換性の問題は紹介されるでしょう。

12.2.1 UAC Behavior

12.2.1 UACの振舞い

12.2.1.1 Generating the Request

12.2.1.1 要求を生成すること。

   A request within a dialog is constructed by using many of the
   components of the state stored as part of the dialog.

対話の中の要求は、対話の一部として保存された状態のコンポーネントの多くを使用することによって、構成されます。

   The URI in the To field of the request MUST be set to the remote URI
   from the dialog state.  The tag in the To header field of the request
   MUST be set to the remote tag of the dialog ID.  The From URI of the
   request MUST be set to the local URI from the dialog state.  The tag
   in the From header field of the request MUST be set to the local tag
   of the dialog ID.  If the value of the remote or local tags is null,
   the tag parameter MUST be omitted from the To or From header fields,
   respectively.

対話状態からリモートURIに要求のTo分野のURIを設定しなければなりません。 対話IDのリモートタグに要求のToヘッダーフィールドにおけるタグを設定しなければなりません。 対話状態から地方のURIに要求のFrom URIを設定しなければなりません。 対話IDの地方のタグに要求のFromヘッダーフィールドにおけるタグを設定しなければなりません。 リモートであるか地方のタグの値がヌルであるなら、ToかFromヘッダーフィールドからタグパラメタをそれぞれ省略しなければなりません。

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

RFC2543との遅れている互換性のためにToからのURIとその後の要求の中のオリジナルの要求におけるFrom分野の用法をします。(RFCは対話識別にURIを使用しました)。 この仕様では、タグだけが対話識別に使用されます。 中間の対話要求における、オリジナルのToとFrom URIの義務的な反映がこの仕様のその後の改正で推奨しなくなると予想されます。

   The Call-ID of the request MUST be set to the Call-ID of the dialog.
   Requests within a dialog MUST contain strictly monotonically
   increasing and contiguous CSeq sequence numbers (increasing-by-one)
   in each direction (excepting ACK and CANCEL of course, whose numbers
   equal the requests being acknowledged or cancelled).  Therefore, if
   the local sequence number is not empty, the value of the local
   sequence number MUST be incremented by one, and this value MUST be
   placed into the CSeq header field.  If the local sequence number is
   empty, an initial value MUST be chosen using the guidelines of
   Section 8.1.1.5.  The method field in the CSeq header field value
   MUST match the method of the request.

対話のCall-IDに要求のCall-IDを設定しなければなりません。 対話の中の要求は各方向(承認されていて、もちろん番号が要求と等しいACKとキャンセルを除くか、または中止される)に厳密に単調に増加して隣接のCSeq一連番号(1つ増加する)を含まなければなりません。 したがって、局所的配列番号が空でないなら、局所的配列番号の値を1つ増加しなければなりません、そして、この値をCSeqヘッダーフィールドに置かなければなりません。 局所的配列番号が空であるなら、.5にセクション8.1.1のガイドラインを使用して、初期の値を選ばなければなりません。 CSeqヘッダーフィールド価値におけるメソッド分野は要求のメソッドに合わなければなりません。

Rosenberg, et. al.          Standards Track                    [Page 73]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[73ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before needing to
      wrap around.  The initial value of the sequence number is chosen
      so that subsequent requests within the same call will not wrap
      around.  A non-zero initial value allows clients to use a time-
      based initial sequence number.  A client could, for example,
      choose the 31 most significant bits of a 32-bit second clock as an
      initial sequence number.

32ビットの長さで、クライアントは巻きつけるのが必要である前に、およそ136年間ただ一つの呼び出しの中で1秒あたり1つの要求を生成することができました。 一連番号の初期の値は、同じ呼び出しの中のその後の要求が巻きつけられないように、選ばれています。 非ゼロの初期の値で、クライアントは初期で基づく時間一連番号を使用できます。 例えば、クライアントは初期シーケンス番号として2番目の32ビットの時計の31の最上位ビットを選ぶことができました。

   The UAC uses the remote target and route set to build the Request-URI
   and Route header field of the request.

UACは、要求のRequest-URIとRouteヘッダーフィールドを築き上げるのにリモート目標とルートセットを使用します。

   If the route set is empty, the UAC MUST place the remote target URI
   into the Request-URI.  The UAC MUST NOT add a Route header field to
   the request.

ルートセットが空であるなら、UAC MUSTはリモート目標URIをRequest-URIに置きます。 UAC MUST NOTはRouteヘッダーフィールドを要求に追加します。

   If the route set is not empty, and the first URI in the route set
   contains the lr parameter (see Section 19.1.1), the UAC MUST place
   the remote target URI into the Request-URI and MUST include a Route
   header field containing the route set values in order, including all
   parameters.

ルートセットが空でなく、ルートセットにおける最初のURIがlrパラメタを含んでいるなら(セクション19.1.1を見てください)、UAC MUSTは整然とした状態でリモート目標URIをRequest-URIに置いて、ルートセット値を含むRouteヘッダーフィールドを含めなければなりません、すべてのパラメタを含んでいて。

   If the route set is not empty, and its first URI does not contain the
   lr parameter, the UAC MUST place the first URI from the route set
   into the Request-URI, stripping any parameters that are not allowed
   in a Request-URI.  The UAC MUST add a Route header field containing
   the remainder of the route set values in order, including all
   parameters.  The UAC MUST then place the remote target URI into the
   Route header field as the last value.

ルートセットが空でなく、また最初のURIがlrパラメタを含んでいないなら、UAC MUSTは最初のURIをルートセットからRequest-URIに置きます、Request-URIで許容されていないどんなパラメタも剥取って。 UAC MUSTは、ルートの残りを含むRouteヘッダーフィールドが値を整理したと言い足します、すべてのパラメタを含んでいて。 そして、UAC MUSTは最終値としてリモート目標URIをRouteヘッダーフィールドに置きます。

   For example, if the remote target is sip:user@remoteua and the route
   set contains:

例えば、セットはリモート目標が一口: user@remoteua とルートであるなら以下を含んでいます。

      <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

<一口: ; <一口: proxy1>、<一口: proxy2>、<一口: proxy3、lr>、proxy4>。

   The request will be formed with the following Request-URI and Route
   header field:

要求は以下のRequest-URIとRouteヘッダーフィールドで形成されるでしょう:

   METHOD sip:proxy1
   Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

METHOD一口: proxy1 Route: <一口: proxy2>、<一口: proxy3; <一口: lr>、<一口: proxy4>、 user@remoteua 、gt。

      If the first URI of the route set does not contain the lr
      parameter, the proxy indicated does not understand the routing
      mechanisms described in this document and will act as specified in
      RFC 2543, replacing the Request-URI with the first Route header
      field value it receives while forwarding the message.  Placing the
      Request-URI at the end of the Route header field preserves the

ルートセットの最初のURIがlrパラメタを含んでいないと、示されたプロキシは、本書では説明されたルーティングメカニズムを理解しないで、RFC2543で指定されるように行動するでしょう、Request-URIをそれがメッセージを転送している間に受ける最初のRouteヘッダーフィールド価値に取り替えて。 ヘッダーフィールドが保存するRouteの端にRequest-URIを置くこと。

Rosenberg, et. al.          Standards Track                    [Page 74]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[74ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      information in that Request-URI across the strict router (it will
      be returned to the Request-URI when the request reaches a loose-
      router).

厳しいルータ(要求がゆるいルータに達するとき、Request-URIにそれを返す)の向こう側のそのRequest-URIにおける情報。

   A UAC SHOULD include a Contact header field in any target refresh
   requests within a dialog, and unless there is a need to change it,
   the URI SHOULD be the same as used in previous requests within the
   dialog.  If the "secure" flag is true, that URI MUST be a SIPS URI.
   As discussed in Section 12.2.2, a Contact header field in a target
   refresh request updates the remote target URI.  This allows a UA to
   provide a new contact address, should its address change during the
   duration of the dialog.

どんな目標のUAC SHOULDインクルードa Contactヘッダーフィールドも対話の中で要求をリフレッシュします、そして、それを変える必要がない場合、同じくらいが前で使用されていたので、URI SHOULDは中で対話を要求します。 「安全な」旗が本当であるなら、そのURIはSIPS URIであるに違いありません。 セクション12.2で議論して、.2、目標のContactヘッダーフィールドがリフレッシュするとき、要求はリモート目標URIをアップデートします。 これで、UAは新しい連絡先を提供できて、持続時間の間の対話のアドレス変化はそうするべきです。

   However, requests that are not target refresh requests do not affect
   the remote target URI for the dialog.

しかしながら、目標が要求をリフレッシュするということでない要求は対話のためのリモート目標URIに影響しません。

   The rest of the request is formed as described in Section 8.1.1.

要求の残りはセクション8.1.1で説明されるように形成されます。

   Once the request has been constructed, the address of the server is
   computed and the request is sent, using the same procedures for
   requests outside of a dialog (Section 8.1.2).

いったん要求を構成すると、サーバのアドレスを計算します、そして、要求を送ります、要求に対話(セクション8.1.2)の外で同じ手順を用いて。

      The procedures in Section 8.1.2 will normally result in the
      request being sent to the address indicated by the topmost Route
      header field value or the Request-URI if no Route header field is
      present.  Subject to certain restrictions, they allow the request
      to be sent to an alternate address (such as a default outbound
      proxy not represented in the route set).

通常、セクション8.1.2における手順はどんなRouteヘッダーフィールドも存在していないなら最上のRouteヘッダーフィールド価値かRequest-URIによって示されたアドレスに送られる要求をもたらすでしょう。 ある制限を条件として、それらは代替アドレス(外国行きのプロキシがルートセットで表さなかったデフォルトなどの)に送られるという要求を許します。

12.2.1.2 Processing the Responses

12.2.1.2 応答を処理すること。

   The UAC will receive responses to the request from the transaction
   layer.  If the client transaction returns a timeout, this is treated
   as a 408 (Request Timeout) response.

UACは取引層から要求への応答を受けるでしょう。 クライアント取引がタイムアウトを返すなら、これは408(Timeoutを要求する)応答として扱われます。

   The behavior of a UAC that receives a 3xx response for a request sent
   within a dialog is the same as if the request had been sent outside a
   dialog.  This behavior is described in Section 8.1.3.4.

対話の中で送られた要求のための3xx応答を受けるUACの動きはまるで対話の外で要求を送ったかのように同じです。 この振舞いはセクション8.1.3で.4に説明されます。

      Note, however, that when the UAC tries alternative locations, it
      still uses the route set for the dialog to build the Route header
      of the request.

しかしながら、UACが代替の位置を試みるとき、対話にまだルートセットを使用していることに注意して、要求のRouteヘッダーを造ってください。

   When a UAC receives a 2xx response to a target refresh request, it
   MUST replace the dialog's remote target URI with the URI from the
   Contact header field in that response, if present.

UACが目標への2xx応答を受けたら要求をリフレッシュしてください、そして、対話のリモート目標URIをその応答におけるContactヘッダーフィールドからURIに取り替えなければなりません、存在しているなら。

Rosenberg, et. al.          Standards Track                    [Page 75]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[75ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   If the response for a request within a dialog is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
   no response at all is received for the request (the client
   transaction would inform the TU about the timeout.)

対話の中の要求のための応答が481(呼び出し/取引Does Not Exist)か408(Timeoutを要求する)であるなら、UAC SHOULDは対話を終えます。 また、要求のために全く応答を全く受けないなら、UAC SHOULDは対話を終えます。(クライアント取引はタイムアウトに関してTUに知らせるでしょう。)

      For INVITE initiated dialogs, terminating the dialog consists of
      sending a BYE.

INVITEに関しては、開始している対話であり、対話を終えるのはBYEを送るのから成ります。

12.2.2 UAS Behavior

12.2.2 UASの振舞い

   Requests sent within a dialog, as any other requests, are atomic.  If
   a particular request is accepted by the UAS, all the state changes
   associated with it are performed.  If the request is rejected, none
   of the state changes are performed.

いかなる他の要求としても対話の中で送られた要求は原子です。 特定の要求がUASによって受け入れられるなら、それに関連しているすべての州の変化が実行されます。 要求が拒絶されるなら、州の変化のいずれも実行されません。

      Note that some requests, such as INVITEs, affect several pieces of
      state.

INVITEsなどのいくつかの要求が数片の状態に影響することに注意してください。

   The UAS will receive the request from the transaction layer.  If the
   request has a tag in the To header field, the UAS core computes the
   dialog identifier corresponding to the request and compares it with
   existing dialogs.  If there is a match, this is a mid-dialog request.
   In that case, the UAS first applies the same processing rules for
   requests outside of a dialog, discussed in Section 8.2.

UASは取引層から要求を受け取るでしょう。 要求がToヘッダーフィールドでタグを持っているなら、UASコアは、要求に対応する対話識別子を計算して、既存の対話とそれを比べます。 マッチがあれば、これは中間の対話要求です。 その場合、UASは最初に、セクション8.2で議論した対話の外に要求のための同じ処理規則を適用します。

   If the request has a tag in the To header field, but the dialog
   identifier does not match any existing dialogs, the UAS may have
   crashed and restarted, or it may have received a request for a
   different (possibly failed) UAS (the UASs can construct the To tags
   so that a UAS can identify that the tag was for a UAS for which it is
   providing recovery).  Another possibility is that the incoming
   request has been simply misrouted.  Based on the To tag, the UAS MAY
   either accept or reject the request.  Accepting the request for
   acceptable To tags provides robustness, so that dialogs can persist
   even through crashes.  UAs wishing to support this capability must
   take into consideration some issues such as choosing monotonically
   increasing CSeq sequence numbers even across reboots, reconstructing
   the route set, and accepting out-of-range RTP timestamps and sequence
   numbers.

要求がToヘッダーフィールドでタグを持っていますが、対話識別子がどんな既存の対話にも合っていないなら、UASがクラッシュして、再開したかもしれませんか、またはそれは異なった(ことによると失敗した)UASを求める要求を受け取ったかもしれません(UASsはUASが、タグがそれが回復を供給しているUASのためのものであったのを特定できるように、Toタグを組み立てることができます)。 別の可能性は入って来る要求が単にmisroutedされたということです。 Toタグに基づいて、UAS MAYは要求を受け入れるか、または拒絶します。 許容できるToタグのために要請を受け入れるのは、対話がクラッシュでさえ持続できるように、丈夫さを提供します。 この能力を支持したがっているUAsはリブートの向こう側にさえCSeq一連番号を単調に増加させるのを選ぶことなどのいくつかの問題を考慮に入れなければなりません、ルートセットを再建して、範囲の外でRTPタイムスタンプと一連番号を受け入れて。

   If the UAS wishes to reject the request because it does not wish to
   recreate the dialog, it MUST respond to the request with a 481
   (Call/Transaction Does Not Exist) status code and pass that to the
   server transaction.

対話を休養させたがっていないのでUASが要求を拒絶したいなら、それは、481(呼び出し/取引Does Not Exist)ステータスコードで要求に応じて、サーバ取引にそれを通過しなければなりません。

Rosenberg, et. al.          Standards Track                    [Page 76]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[76ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Requests that do not change in any way the state of a dialog may be
   received within a dialog (for example, an OPTIONS request).  They are
   processed as if they had been received outside the dialog.

対話(例えば、OPTIONS要求)の中に何らかの方法で対話の状態を変えない要求を受け取るかもしれません。 それらはまるで対話の外でそれらを受け取ったかのように処理されます。

   If the remote sequence number is empty, it MUST be set to the value
   of the sequence number in the CSeq header field value in the request.
   If the remote sequence number was not empty, but the sequence number
   of the request is lower than the remote sequence number, the request
   is out of order and MUST be rejected with a 500 (Server Internal
   Error) response.  If the remote sequence number was not empty, and
   the sequence number of the request is greater than the remote
   sequence number, the request is in order.  It is possible for the
   CSeq sequence number to be higher than the remote sequence number by
   more than one.  This is not an error condition, and a UAS SHOULD be
   prepared to receive and process requests with CSeq values more than
   one higher than the previous received request.  The UAS MUST then set
   the remote sequence number to the value of the sequence number in the
   CSeq header field value in the request.

リモート一連番号が空であるなら、それは要求におけるCSeqヘッダーフィールド価値における、一連番号の値へのセットであるに違いありません。 リモート一連番号が空ではありませんでしたが、要求の一連番号がリモート一連番号より低いなら、要求を故障していて、500(サーバInternal Error)応答で拒絶しなければなりません。 リモート一連番号が空でなく、要求の一連番号がリモート一連番号より大きいなら、要求は整然としています。 CSeq一連番号が、より1時までにリモート一連番号より高いのは、可能です。 これがエラー条件でなく、UAS SHOULDは受信するように準備されて、要求を処理します。1より多くのCSeq値が前が要求を受け取ったより高い状態で。 そして、UAS MUSTは要求におけるCSeqヘッダーフィールド価値における、一連番号の値にリモート一連番号を設定します。

      If a proxy challenges a request generated by the UAC, the UAC has
      to resubmit the request with credentials.  The resubmitted request
      will have a new CSeq number.  The UAS will never see the first
      request, and thus, it will notice a gap in the CSeq number space.
      Such a gap does not represent any error condition.

プロキシがUACによって発生した要求に挑戦するなら、UACは信任状で要求を再提出しなければなりません。 再提出された要求には、新しいCSeq番号があるでしょう。 UASは最初の要求を決して見ないでしょう、そして、その結果、それはCSeq数のスペースでギャップに気付くでしょう。 そのようなギャップはどんなエラー条件も表しません。

   When a UAS receives a target refresh request, it MUST replace the
   dialog's remote target URI with the URI from the Contact header field
   in that request, if present.

UASが受信するとき、目標は要求をリフレッシュして、対話のリモート目標URIをその要求におけるContactヘッダーフィールドからURIに取り替えなければなりません、存在しているなら。

12.3 Termination of a Dialog

12.3 対話の終了

   Independent of the method, if a request outside of a dialog generates
   a non-2xx final response, any early dialogs created through
   provisional responses to that request are terminated.  The mechanism
   for terminating confirmed dialogs is method specific.  In this
   specification, the BYE method terminates a session and the dialog
   associated with it.  See Section 15 for details.

方法から独立しています、対話の外部は要求であるなら非2xxの最終的な応答を発生させて、その要求への暫定的な応答で作成されたどんな早めの対話も終えられます。 終わりが対話を確認したので、メカニズムは方法特有です。 この仕様では、BYE方法はそれに関連しているセッションと対話を終えます。 詳細に関してセクション15を見てください。

13 Initiating a Session

13 セッションを開始すること。

13.1 Overview

13.1 概観

   When a user agent client desires to initiate a session (for example,
   audio, video, or a game), it formulates an INVITE request.  The
   INVITE request asks a server to establish a session.  This request
   may be forwarded by proxies, eventually arriving at one or more UAS
   that can potentially accept the invitation.  These UASs will
   frequently need to query the user about whether to accept the

ユーザエージェントのクライアントが、セッション(例えば、オーディオ、ビデオ、またはゲーム)を開始することを望んでいるとき、それはINVITE要求を定式化します。 INVITE要求は、セッションを証明するためにサーバを尋ねます。 結局潜在的に招待に応じることができる1UASに到着して、この要求はプロキシによって転送されるかもしれません。 これらのUASsは、頻繁に受け入れるかどうかをユーザについて質問する必要があるでしょう。

Rosenberg, et. al.          Standards Track                    [Page 77]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[77ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   invitation.  After some time, those UASs can accept the invitation
   (meaning the session is to be established) by sending a 2xx response.
   If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
   sent, depending on the reason for the rejection.  Before sending a
   final response, the UAS can also send provisional responses (1xx) to
   advise the UAC of progress in contacting the called user.

招待。 いつか後に、2xx応答を送ることによって、それらのUASsは招待(セッションが設立されることであることを意味する)に応じることができます。 招待に応じないなら、3xx、4xx、5xxまたは6xx応答を送ります、拒絶の理由によって。 また、最終的な応答を送る前に、UASは、呼ばれたユーザに連絡する際に進歩をUACに知らせるために、暫定的な応答(1xx)を送ることができます。

   After possibly receiving one or more provisional responses, the UAC
   will get one or more 2xx responses or one non-2xx final response.
   Because of the protracted amount of time it can take to receive final
   responses to INVITE, the reliability mechanisms for INVITE
   transactions differ from those of other requests (like OPTIONS).
   Once it receives a final response, the UAC needs to send an ACK for
   every final response it receives.  The procedure for sending this ACK
   depends on the type of response.  For final responses between 300 and
   699, the ACK processing is done in the transaction layer and follows
   one set of rules (See Section 17).  For 2xx responses, the ACK is
   generated by the UAC core.

ことによると1つ以上の暫定的な応答を受けた後に、UACは1つ以上の2xx応答か1つの非2xxの最終的な応答を得るでしょう。 INVITEへの最終的な応答を受けるにはかかるかもしれない延長された時間のために、INVITE取引のための信頼性のメカニズムは他の要求(OPTIONSのような)のものと異なっています。 いったん最終的な応答を受けると、UACは、それが受けるあらゆる最終的な応答のためにACKを送る必要があります。 このACKを送るための手順は応答のタイプに頼っています。 300と699の間の最終的な応答のために、ACK処理は、取引層の中でして、1セットの規則に従います(セクション17を見てください)。 2xx応答において、ACKはUACコアで発生します。

   A 2xx response to an INVITE establishes a session, and it also
   creates a dialog between the UA that issued the INVITE and the UA
   that generated the 2xx response.  Therefore, when multiple 2xx
   responses are received from different remote UAs (because the INVITE
   forked), each 2xx establishes a different dialog.  All these dialogs
   are part of the same call.

INVITEへの2xx応答はセッションを確立します、そして、また、それはINVITEを発行したUAと2xx応答を発生させたUAの間で対話を作成します。 したがって、異なったリモートUAsから複数の2xx応答を受けるとき(INVITEが分岐したので)、各2xxは異なった対話を確立します。 これらのすべての対話が同じ呼び出しの一部です。

   This section provides details on the establishment of a session using
   INVITE.  A UA that supports INVITE MUST also support ACK, CANCEL and
   BYE.

このセクションは、INVITEを使用することでセッションの設立に関する詳細を明らかにします。 また、INVITE MUSTを支持するUAはACK、キャンセル、およびBYEを支持します。

13.2 UAC Processing

13.2 UAC処理

13.2.1 Creating the Initial INVITE

13.2.1 初期が招待する作成

   Since the initial INVITE represents a request outside of a dialog,
   its construction follows the procedures of Section 8.1.1.  Additional
   processing is required for the specific case of INVITE.

初期のINVITEが対話の外に要求を表すので、工事はセクション8.1.1の手順に従います。 追加処理がINVITEの特定のケースに必要です。

   An Allow header field (Section 20.5) SHOULD be present in the INVITE.
   It indicates what methods can be invoked within a dialog, on the UA
   sending the INVITE, for the duration of the dialog.  For example, a
   UA capable of receiving INFO requests within a dialog [34] SHOULD
   include an Allow header field listing the INFO method.

Allowヘッダーは現在のコネがINVITEであったならSHOULDをさばきます(セクション20.5)。 それは、対話の中にどんな方法を呼び出すことができるかを示します、INVITEを送るUAで、対話の持続時間のために。 例えば、INFOを受けることができるUAは、対話の中で[34] SHOULDがINFO方法を記載するAllowヘッダーフィールドを含んでいるよう要求します。

   A Supported header field (Section 20.37) SHOULD be present in the
   INVITE.  It enumerates all the extensions understood by the UAC.

Supportedヘッダーは現在のコネがINVITEであったならSHOULDをさばきます(セクション20.37)。 それはUACに解釈されたすべての拡大を列挙します。

Rosenberg, et. al.          Standards Track                    [Page 78]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[78ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   An Accept (Section 20.1) header field MAY be present in the INVITE.
   It indicates which Content-Types are acceptable to the UA, in both
   the response received by it, and in any subsequent requests sent to
   it within dialogs established by the INVITE.  The Accept header field
   is especially useful for indicating support of various session
   description formats.

Accept(セクション20.1)ヘッダーフィールドはINVITEに存在しているかもしれません。 それは、どのコンテントタイプがUAに許容できるかを示します、応答がそれの近くと、そして、INVITEによって確立された対話の中でそれに送られたどんなその後の要求でも受けた両方で。 Acceptヘッダーフィールドは特に様々なセッション記述形式のサポートを示すことの役に立ちます。

   The UAC MAY add an Expires header field (Section 20.19) to limit the
   validity of the invitation.  If the time indicated in the Expires
   header field is reached and no final answer for the INVITE has been
   received, the UAC core SHOULD generate a CANCEL request for the
   INVITE, as per Section 9.

UAC MAYは、招待の正当性を制限するために、Expiresヘッダーフィールド(セクション20.19)を加えます。 Expiresヘッダーフィールドで示された時間に達していて、INVITEのためのどんな最終的な答えも受けていないなら、UACコアSHOULDはINVITEを求めるキャンセル要求を発生させます、セクション9に従って。

   A UAC MAY also find it useful to add, among others, Subject (Section
   20.36), Organization (Section 20.25) and User-Agent (Section 20.41)
   header fields.  They all contain information related to the INVITE.

また、UAC MAYは、特に加えるのが役に立つのがわかります、Subject(セクション20.36)、Organization(セクション20.25)とUser-エージェント(セクション20.41)ヘッダーフィールド。 それらは皆、INVITEに関連する情報を含んでいます。

   The UAC MAY choose to add a message body to the INVITE.  Section
   8.1.1.10 deals with how to construct the header fields -- Content-
   Type among others -- needed to describe the message body.

UAC MAYは、メッセージ本体をINVITEに加えるのを選びます。 セクション8.1 .1 どうヘッダーフィールドを構成するかとの.10の取引(特に内容タイプ)が、メッセージ本体について説明する必要がありました。

   There are special rules for message bodies that contain a session
   description - their corresponding Content-Disposition is "session".
   SIP uses an offer/answer model where one UA sends a session
   description, called the offer, which contains a proposed description
   of the session.  The offer indicates the desired communications means
   (audio, video, games), parameters of those means (such as codec
   types) and addresses for receiving media from the answerer.  The
   other UA responds with another session description, called the
   answer, which indicates which communications means are accepted, the
   parameters that apply to those means, and addresses for receiving
   media from the offerer. An offer/answer exchange is within the
   context of a dialog, so that if a SIP INVITE results in multiple
   dialogs, each is a separate offer/answer exchange.  The offer/answer
   model defines restrictions on when offers and answers can be made
   (for example, you cannot make a new offer while one is in progress).
   This results in restrictions on where the offers and answers can
   appear in SIP messages.  In this specification, offers and answers
   can only appear in INVITE requests and responses, and ACK.  The usage
   of offers and answers is further restricted.  For the initial INVITE
   transaction, the rules are:

セッション記述を含むメッセージ本体のための特別な規則があります--彼らの対応するContent-気質は「セッション」です。 SIPは1UAがセッションの提案された記述を含む申し出と呼ばれるセッション記述を送る申し出/答えモデルを使用します。 申し出が必要なコミュニケーション手段(オーディオ、ビデオ、ゲーム)を示して、それらのパラメタは、answererからメディアを受け取るための手段(コーデックタイプなどの)とアドレスです。 もう片方のUAはどのコミュニケーション手段が受け入れられるかを示す答えと呼ばれる別のセッション記述、申出人からメディアを受け取るためにそれらの手段、およびアドレスに適用されるパラメタで応じます。 対話の文脈の中に申し出/答え交換があります、SIP INVITEが複数の対話をもたらすなら、それぞれが別々の申し出/答え交換であるように。 申し出/答えモデルは申し出と答えをすることができる(例えば、あなたは1つが進行している間、新しい申し出をすることができません)時に関する制限を定義します。 これは申し出と答えがSIPメッセージに現れることができるところに関する制限をもたらします。 この仕様では、申し出と答えはINVITE要求、応答、およびACKに現れることができるだけです。 申し出と答えの用法はさらに制限されます。 初期のINVITE取引のために、規則は以下の通りです。

      o  The initial offer MUST be in either an INVITE or, if not there,
         in the first reliable non-failure message from the UAS back to
         the UAC.  In this specification, that is the final 2xx
         response.

o 初期の申し出は、INVITEになければならないか、またはそこでないなら、最初の信頼できる非失敗でUASからUACまで通信しなければなりません。 この仕様では、それは最終的な2xx応答です。

Rosenberg, et. al.          Standards Track                    [Page 79]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[79ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

o 初期の申し出がINVITEにあるなら、UASからそのINVITEに関連するUACまで答えが信頼できる非失敗メッセージにあるに違いありません。 この仕様に関しては、唯一のそれはそのINVITEへの最終的な2xx応答です。 また、その同じ正確な答えは答えの前に送られたどんな暫定的な応答にも置かれるかもしれません。 UAC MUSTはそれが受ける最初のセッション記述を答えとして扱って、初期のINVITEへのその後の応答におけるどんなセッション記述も無視しなければなりません。

      o  If the initial offer is in the first reliable non-failure
         message from the UAS back to UAC, the answer MUST be in the
         acknowledgement for that message (in this specification, ACK
         for a 2xx response).

o UASからUACまで初期の申し出が最初の信頼できる非失敗メッセージにあるなら、答えはそのメッセージ(2xx応答のためのこの仕様のACK)のための承認中であるに違いありません。

      o  After having sent or received an answer to the first offer, the
         UAC MAY generate subsequent offers in requests based on rules
         specified for that method, but only if it has received answers
         to any previous offers, and has not sent any offers to which it
         hasn't gotten an answer.

o 最初の申し出の答えを送るか、または受けた後に、UAC MAYはそれがその方法にもかかわらず、何か前の申し出の答えを受けて、何か答を出していない申し出を送るだけではないかどうかに指定された規則に基づいて要求におけるその後の申し出を発生させます。

      o  Once the UAS has sent or received an answer to the initial
         offer, it MUST NOT generate subsequent offers in any responses
         to the initial INVITE.  This means that a UAS based on this
         specification alone can never generate subsequent offers until
         completion of the initial transaction.

o UASがいったん初期の申し出の答えを送るか、または受けると、それは初期のINVITEへのどんな応答でもその後の申し出を発生させてはいけません。 これは、単独でこの仕様に基づくUASがその後の申し出を決して初期の取引の完成まで発生させることができないことを意味します。

   Concretely, the above rules specify two exchanges for UAs compliant
   to this specification alone - the offer is in the INVITE, and the
   answer in the 2xx (and possibly in a 1xx as well, with the same
   value), or the offer is in the 2xx, and the answer is in the ACK.
   All user agents that support INVITE MUST support these two exchanges.

具体的に、上の規則は単独でこの仕様に言いなりになっているUAsへの2回の交換を指定します--申し出が2xxにあります、そして、申し出がINVITE、および答え2xx(そしてことによるとまた、同じ値がある1xxで)で中です、または答えがACKにあります。 INVITE MUSTを支持するすべてのユーザエージェントがこれらの2回の交換を支持します。

   The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be
   supported by all user agents as a means to describe sessions, and its
   usage for constructing offers and answers MUST follow the procedures
   defined in [13].

Session記述プロトコル、(SDP) (すべてのユーザエージェントがセッションについて説明する手段としてRFC2327[1])を支持しなければならなくて、申し出と答えを構成するための用法は[13]で定義された手順に従わなければなりません。

   The restrictions of the offer-answer model just described only apply
   to bodies whose Content-Disposition header field value is "session".
   Therefore, it is possible that both the INVITE and the ACK contain a
   body message (for example, the INVITE carries a photo (Content-
   Disposition: render) and the ACK a session description (Content-
   Disposition: session)).

ただ説明された申し出答えモデルの制限はContent-気質ヘッダーフィールド価値が「セッション」であるボディーに適用されるだけです。 例えば、INVITEは写真を運びます。したがって、INVITEとACKの両方がボディーメッセージを含むのが、可能である、((気質を満足させてください:、レンダリング、)、そして、ACK aセッション記述(内容気質: セッション)。

   If the Content-Disposition header field is missing, bodies of
   Content-Type application/sdp imply the disposition "session", while
   other content types imply "render".

Content-気質ヘッダーフィールドがなくなるなら、コンテントタイプアプリケーション/sdpのボディーは気質「セッション」を含意します、他の満足しているタイプは「レンダリング」について暗示しますが。

Rosenberg, et. al.          Standards Track                    [Page 80]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[80ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Once the INVITE has been created, the UAC follows the procedures
   defined for sending requests outside of a dialog (Section 8).  This
   results in the construction of a client transaction that will
   ultimately send the request and deliver responses to the UAC.

INVITEがいったん作成されると、UACは対話(セクション8)の外に送付要求のために定義された手順に従います。 これは結局、要求を送って、UACへの応答を提供するクライアント取引の工事をもたらします。

13.2.2 Processing INVITE Responses

13.2.2 処理して、応答を招待してください。

   Once the INVITE has been passed to the INVITE client transaction, the
   UAC waits for responses for the INVITE.  If the INVITE client
   transaction returns a timeout rather than a response the TU acts as
   if a 408 (Request Timeout) response had been received, as described
   in Section 8.1.3.

INVITEがいったんINVITEクライアント取引に渡されると、UACはINVITEのために応答を待っています。 INVITEクライアント取引が応答よりむしろタイムアウトを返すなら、TUはまるで408(Timeoutを要求する)応答を受けたかのように行動します、セクション8.1.3で説明されるように。

13.2.2.1 1xx Responses

13.2.2.1 1 xx応答

   Zero, one or multiple provisional responses may arrive before one or
   more final responses are received.  Provisional responses for an
   INVITE request can create "early dialogs".  If a provisional response
   has a tag in the To field, and if the dialog ID of the response does
   not match an existing dialog, one is constructed using the procedures
   defined in Section 12.1.2.

1つ以上の最終的な応答が受け取られている前にゼロ、1または複数の暫定的な応答が到着するかもしれません。 INVITE要求のための暫定的な応答は「早めの対話」を作成できます。 応答の対話IDが既存の対話に合っていないなら暫定的な応答がTo分野にタグを持っているなら、1つは、セクション12.1.2で定義された手順を用いることで組み立てられます。

   The early dialog will only be needed if the UAC needs to send a
   request to its peer within the dialog before the initial INVITE
   transaction completes.  Header fields present in a provisional
   response are applicable as long as the dialog is in the early state
   (for example, an Allow header field in a provisional response
   contains the methods that can be used in the dialog while this is in
   the early state).

UACが、初期のINVITE取引の前に対話の中で要求を同輩に送る必要がある場合にだけ、早めの対話が必要でしょう。完成します。 対話が早めの状態にある(例えば、暫定的な応答におけるAllowヘッダーフィールドはこれが早めの状態にある間対話に使用できる方法を含んでいます)限り、暫定的な応答における現在のヘッダーフィールドは適切です。

13.2.2.2 3xx Responses

13.2.2.2 3 xx応答

   A 3xx response may contain one or more Contact header field values
   providing new addresses where the callee might be reachable.
   Depending on the status code of the 3xx response (see Section 21.3),
   the UAC MAY choose to try those new addresses.

3xx応答は訪問される人が届くかもしれない新しいアドレスを提供する1つ以上のContactヘッダーフィールド値を含むかもしれません。 3xx応答(セクション21.3を見る)のステータスコードによって、UAC MAYは、それらの新しいアドレスを試みるのを選びます。

13.2.2.3 4xx, 5xx and 6xx Responses

13.2.2.3 4 xx、5xx、および6xx応答

   A single non-2xx final response may be received for the INVITE.  4xx,
   5xx and 6xx responses may contain a Contact header field value
   indicating the location where additional information about the error
   can be found.  Subsequent final responses (which would only arrive
   under error conditions) MUST be ignored.

INVITEのためにただ一つの非2xx最終的な応答を受けるかもしれません。 4xx、5xx、および6xx応答は誤りに関する追加情報を見つけることができる位置を示すContactヘッダーフィールド価値を含むかもしれません。 その後の最終的な応答(エラー条件の下で到着するだけである)を無視しなければなりません。

   All early dialogs are considered terminated upon reception of the
   non-2xx final response.

すべての早めの対話が非2xxの最終的な応答のレセプションで終えられた状態で考えられます。

Rosenberg, et. al.          Standards Track                    [Page 81]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[81ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   After having received the non-2xx final response the UAC core
   considers the INVITE transaction completed.  The INVITE client
   transaction handles the generation of ACKs for the response (see
   Section 17).

UACコアが取引が完成したINVITEであると考える非2xxの最終的な応答を受けた後に。 INVITEクライアント取引は応答のためにACKsの世代を扱います(セクション17を見てください)。

13.2.2.4 2xx Responses

13.2.2.4 2 xx応答

   Multiple 2xx responses may arrive at the UAC for a single INVITE
   request due to a forking proxy.  Each response is distinguished by
   the tag parameter in the To header field, and each represents a
   distinct dialog, with a distinct dialog identifier.

複数の2xx応答が分岐しているプロキシによるただ一つのINVITE要求のためにUACに到着するかもしれません。 各応答はToヘッダーフィールドにおけるタグパラメタによって区別されます、そして、それぞれが異なった対話を表します、異なった対話識別子で。

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.

2xx応答における対話識別子が既存の対話に関する対話識別子に合っているなら、対話は、「確認された」状態に移行していて.2にセクション12.2.1の手順を用いて、2xx応答に基づいて対話を再計算しなければならないので設定されたルートであるに違いありません。 さもなければ、セクション12.1.2の手順を用いて、「確認された」状態での新しい対話を構成しなければなりません。

      Note that the only piece of state that is recomputed is the route
      set.  Other pieces of state such as the highest sequence numbers
      (remote and local) sent within the dialog are not recomputed.  The
      route set only is recomputed for backwards compatibility.  RFC
      2543 did not mandate mirroring of the Record-Route header field in
      a 1xx, only 2xx.  However, we cannot update the entire state of
      the dialog, since mid-dialog requests may have been sent within
      the early dialog, modifying the sequence numbers, for example.

再計算される唯一の状態がルートセットであることに注意してください。 対話の中で送られた中で最も高い一連番号(リモートで地方の)などの状態の他の断片は再計算されません。 ルートセットだけが遅れている互換性のために再計算されます。 RFC2543は1xx、2xxだけでRecord-ルートヘッダーフィールドのミラーリングを強制しませんでした。 しかしながら、私たちは対話の全体の州をアップデートできません、早めの対話の中で中間の対話要求を送ったかもしれないので、例えば一連番号を変更して

   The UAC core MUST generate an ACK request for each 2xx received from
   the transaction layer.  The header fields of the ACK are constructed
   in the same way as for any request sent within a dialog (see Section
   12) with the exception of the CSeq and the header fields related to
   authentication.  The sequence number of the CSeq header field MUST be
   the same as the INVITE being acknowledged, but the CSeq method MUST
   be ACK.  The ACK MUST contain the same credentials as the INVITE.  If
   the 2xx contains an offer (based on the rules above), the ACK MUST
   carry an answer in its body.  If the offer in the 2xx response is not
   acceptable, the UAC core MUST generate a valid answer in the ACK and
   then send a BYE immediately.

UACコアは取引層から受け取られた各2xxを求めるACK要求を発生させなければなりません。 同様に、認証に関連するCSeqとヘッダーフィールドを除いて、ACKのヘッダーフィールドは対話(セクション12を見る)の中で送られたどんな要求のようにも構成されます。 CSeqヘッダーフィールドの一連番号は承認されるINVITEと同じであるに違いありませんが、CSeq方法はACKであるに違いありません。 ACK MUSTはINVITEと同じ信任状を含んでいます。 2xxが申し出(上で規則に基づいている)を含んでいるなら、ACK MUSTはボディーで答えを運びます。 2xx応答における申し出が許容できないなら、UACコアは、ACKで有効な答えを発生させて、すぐに、BYEを送らなければなりません。

   Once the ACK has been constructed, the procedures of [4] are used to
   determine the destination address, port and transport.  However, the
   request is passed to the transport layer directly for transmission,
   rather than a client transaction.  This is because the UAC core
   handles retransmissions of the ACK, not the transaction layer.  The
   ACK MUST be passed to the client transport every time a
   retransmission of the 2xx final response that triggered the ACK
   arrives.

ACKがいったん組み立てられると、[4]の手順は、送付先アドレス、ポート、および輸送を決定するのに用いられます。 しかしながら、要求は直接クライアント取引よりむしろトランスミッションのためにトランスポート層に合格されます。 これはUACコアが取引層ではなく、ACKの「再-トランスミッション」を扱うからです。 ACK MUST、ACKの引き金となった2xxの最終的な応答の「再-トランスミッション」が届くときはいつも、クライアント輸送に通過されてください。

Rosenberg, et. al.          Standards Track                    [Page 82]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[82ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response.  At this point all the
   early dialogs that have not transitioned to established dialogs are
   terminated.  Once the INVITE transaction is considered completed by
   the UAC core, no more new 2xx responses are expected to arrive.

UACコアは、INVITEが最初の2xx応答のレセプションの64*T1秒後に完了された取引であると考えます。 ここに、確立した対話に移行するというわけではなかったすべての早めの対話が終えられます。 INVITE取引がUACコアによって完成しているといったん考えられると、それ以上の新しい2xx応答が到着すると予想されません。

   If, after acknowledging any 2xx response to an INVITE, the UAC does
   not want to continue with that dialog, then the UAC MUST terminate
   the dialog by sending a BYE request as described in Section 15.

INVITEへのどんな2xx応答も承諾した後にUACがその対話を続行したくないなら、UAC MUSTは、セクション15で説明されるようにBYE要求を送ることによって、対話を終えます。

13.3 UAS Processing

13.3 UAS処理

13.3.1 Processing of the INVITE

13.3.1 招待の処理

   The UAS core will receive INVITE requests from the transaction layer.
   It first performs the request processing procedures of Section 8.2,
   which are applied for both requests inside and outside of a dialog.

UASコアは取引層からINVITE要求を受け取るでしょう。 それは最初にセクション8.2の要求現像処理を実行して、どれが申し込まれるかがともに対話の内外を要求します。

   Assuming these processing states are completed without generating a
   response, the UAS core performs the additional processing steps:

これらの処理州が応答を発生させないで完成すると仮定して、UASコアは以下の追加処理ステップを実行します:

      1. If the request is an INVITE that contains an Expires header
         field, the UAS core sets a timer for the number of seconds
         indicated in the header field value.  When the timer fires, the
         invitation is considered to be expired.  If the invitation
         expires before the UAS has generated a final response, a 487
         (Request Terminated) response SHOULD be generated.

1. 要求がExpiresヘッダーフィールドを含むINVITEであるなら、UASコアはヘッダーフィールド値で示された秒数にタイマを設定します。 タイマが撃たれるとき、招待が吐き出されると考えられます。 招待がUASの前で期限が切れるなら、発生しているa最終的な応答、a487(Terminatedを要求する)応答SHOULDは発生しましたか?

      2. If the request is a mid-dialog request, the method-independent
         processing described in Section 12.2.2 is first applied.  It
         might also modify the session; Section 14 provides details.

2. 要求が中間の対話要求であるなら、セクション12.2.2で説明された方法から独立している処理は最初に、適用されます。 また、それはセッションを変更するかもしれません。 セクション14は詳細を明らかにします。

      3. If the request has a tag in the To header field but the dialog
         identifier does not match any of the existing dialogs, the UAS
         may have crashed and restarted, or may have received a request
         for a different (possibly failed) UAS.  Section 12.2.2 provides
         guidelines to achieve a robust behavior under such a situation.

3. 要求がToヘッダーフィールドでタグを持っていますが、対話識別子が既存の対話のいずれにも合っていないなら、UASはクラッシュして、再開したか、または異なった(ことによると失敗した)UASを求める要求を受け取ったかもしれません。 セクション12.2 .2 体力を要しているそのような状況の下での振舞いを達成するためにガイドラインを提供します。

   Processing from here forward assumes that the INVITE is outside of a
   dialog, and is thus for the purposes of establishing a new session.

ここから前方に処理するのは新しいセッションを確立する目的のためにINVITEが対話の外にあって、その結果、あると仮定します。

   The INVITE may contain a session description, in which case the UAS
   is being presented with an offer for that session.  It is possible
   that the user is already a participant in that session, even though
   the INVITE is outside of a dialog.  This can happen when a user is
   invited to the same multicast conference by multiple other
   participants.  If desired, the UAS MAY use identifiers within the
   session description to detect this duplication.  For example, SDP

INVITEはセッション記述を含むかもしれません、その場合、そのセッションのために申し出をUASに与えています。 ユーザが既にそのセッションの関係者であることは可能です、INVITEが対話の外にありますが。 ユーザが複数の他の関係者によって同じマルチキャスト会議に招待されるとき、これは起こることができます。 望まれているなら、UAS MAYは、この複製を検出するのにセッション記述の中で識別子を使用します。 例えば、SDP

Rosenberg, et. al.          Standards Track                    [Page 83]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[83ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   contains a session id and version number in the origin (o) field.  If
   the user is already a member of the session, and the session
   parameters contained in the session description have not changed, the
   UAS MAY silently accept the INVITE (that is, send a 2xx response
   without prompting the user).

起源(o)分野にセッションイドとバージョン番号を保管しています。 ユーザが既にセッションのメンバーであり、セッション記述に含まれたセッションパラメタが変化していないなら、UAS MAYは静かに、INVITE(すなわち、ユーザをうながさないで、2xx応答を送る)を受け入れます。

   If the INVITE does not contain a session description, the UAS is
   being asked to participate in a session, and the UAC has asked that
   the UAS provide the offer of the session.  It MUST provide the offer
   in its first non-failure reliable message back to the UAC.  In this
   specification, that is a 2xx response to the INVITE.

INVITEがセッション記述を含んでいないなら、UASが会議に参加するように頼まれていて、UACは、UASがセッションの申し出を提供するように頼みました。 それはUACへの最初の非失敗信頼できるメッセージに申し出を提供しなければなりません。 この仕様では、それはINVITEへの2xx応答です。

   The UAS can indicate progress, accept, redirect, or reject the
   invitation.  In all of these cases, it formulates a response using
   the procedures described in Section 8.2.6.

UASは、招待を進歩をするか、応じるか、向け直すか、または拒絶するように示すことができます。 これらの場合では、全部で、それは、セクション8.2.6で説明された手順を用いることで応答を定式化します。

13.3.1.1 Progress

13.3.1.1 進歩

   If the UAS is not able to answer the invitation immediately, it can
   choose to indicate some kind of progress to the UAC (for example, an
   indication that a phone is ringing).  This is accomplished with a
   provisional response between 101 and 199.  These provisional
   responses establish early dialogs and therefore follow the procedures
   of Section 12.1.1 in addition to those of Section 8.2.6.  A UAS MAY
   send as many provisional responses as it likes.  Each of these MUST
   indicate the same dialog ID.  However, these will not be delivered
   reliably.

UASがすぐに招待に答えることができないなら、それは、UAC(例えば、電話が鳴っているという指示)へのある種の進歩を示すのを選ぶことができます。 暫定的な応答が101と199の間ある状態で、これは達成されます。 これらの暫定的な応答は、早めの対話を確立して、したがって、セクション8.2.6のものに加えたセクション12.1.1の手順に従います。 UAS MAYは好きなだけ多くの暫定的な応答を送ります。 それぞれのこれらは同じ対話IDを示さなければなりません。 しかしながら、これらは確かに渡されないでしょう。

   If the UAS desires an extended period of time to answer the INVITE,
   it will need to ask for an "extension" in order to prevent proxies
   from canceling the transaction.  A proxy has the option of canceling
   a transaction when there is a gap of 3 minutes between responses in a
   transaction.  To prevent cancellation, the UAS MUST send a non-100
   provisional response at every minute, to handle the possibility of
   lost provisional responses.

UASがINVITEに答える時間の長期間を望んでいると、それは、プロキシが取引を中止するのを防ぐために「拡大」を求める必要があるでしょう。 プロキシには、取引における応答の間に3分の隙間があるとき取引を中止するオプションがあります。 キャンセルを防ぐなら、UAS MUSTは、毎分、無くなっている暫定的な応答の可能性を扱うために非100の暫定的な応答を送ります。

      An INVITE transaction can go on for extended durations when the
      user is placed on hold, or when interworking with PSTN systems
      which allow communications to take place without answering the
      call.  The latter is common in Interactive Voice Response (IVR)
      systems.

ユーザが保持に置かれるか、またはPSTNと共にコミュニケーションが電話口に出ないで行われるシステムを織り込むとき、INVITE取引は拡張持続時間に近づくことができます。 後者はInteractive Voice Response(IVR)システムで一般的です。

13.3.1.2 The INVITE is Redirected

13.3.1.2 INVITEはRedirectedです。

   If the UAS decides to redirect the call, a 3xx response is sent.  A
   300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved
   Temporarily) response SHOULD contain a Contact header field

UASが、呼び出しを向け直すと決めるなら、3xx応答を送ります。 300(複数のChoices)、301(Permanentlyを動かす)または302(Temporarilyを動かします)応答SHOULDがContactヘッダーフィールドを含んでいます。

Rosenberg, et. al.          Standards Track                    [Page 84]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[84ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   containing one or more URIs of new addresses to be tried.  The
   response is passed to the INVITE server transaction, which will deal
   with its retransmissions.

試みられるために新しいアドレスの1つ以上のURIを含んでいます。 応答はINVITEサーバ取引に通過されます。(それは、「再-トランスミッション」に対処するでしょう)。

13.3.1.3 The INVITE is Rejected

13.3.1.3 INVITEはRejectedです。

   A common scenario occurs when the callee is currently not willing or
   able to take additional calls at this end system.  A 486 (Busy Here)
   SHOULD be returned in such a scenario.  If the UAS knows that no
   other end system will be able to accept this call, a 600 (Busy
   Everywhere) response SHOULD be sent instead.  However, it is unlikely
   that a UAS will be able to know this in general, and thus this
   response will not usually be used.  The response is passed to the
   INVITE server transaction, which will deal with its retransmissions.

訪問される人が現在、望んでいないか、またはこのエンドシステムで追加呼び出しを取ることができるとき、共通したシナリオは起こります。 486 (返されたコネがそのようなシナリオであったならHere) SHOULDと忙しくしてください。 UASが、他のどんなエンドシステムもこの呼び出し、600(忙しいEverywhere)応答SHOULDを受け入れることができないのを知っているなら、代わりに送ってください。 しかしながら、一般に、UASがこれを知ることができるのが、ありそうもなく、その結果、通常、この応答は使用されないでしょう。 応答はINVITEサーバ取引に通過されます。(それは、「再-トランスミッション」に対処するでしょう)。

   A UAS rejecting an offer contained in an INVITE SHOULD return a 488
   (Not Acceptable Here) response.  Such a response SHOULD include a
   Warning header field value explaining why the offer was rejected.

申し出を拒絶するUASはINVITE SHOULDリターンで488(Acceptable Hereでない)応答を含みました。 そのような応答SHOULDは申し出がなぜ拒絶されたかがわかるWarningヘッダーフィールド価値を含んでいます。

13.3.1.4 The INVITE is Accepted

13.3.1.4 INVITEはAcceptedです。

   The UAS core generates a 2xx response.  This response establishes a
   dialog, and therefore follows the procedures of Section 12.1.1 in
   addition to those of Section 8.2.6.

UASコアは2xx応答を発生させます。 この応答は、対話を確立して、したがって、セクション8.2.6のものに加えたセクション12.1.1の手順に従います。

   A 2xx response to an INVITE SHOULD contain the Allow header field and
   the Supported header field, and MAY contain the Accept header field.
   Including these header fields allows the UAC to determine the
   features and extensions supported by the UAS for the duration of the
   call, without probing.

INVITE SHOULDへの2xx応答は、AllowヘッダーフィールドとSupportedヘッダーフィールドを含んでいて、Acceptヘッダーフィールドを含むかもしれません。 これらのヘッダーフィールドを含んでいるのに、UACは調べることのない呼び出しの持続時間のためにUASによって支持された特徴と拡大を決定できます。

   If the INVITE request contained an offer, and the UAS had not yet
   sent an answer, the 2xx MUST contain an answer.  If the INVITE did
   not contain an offer, the 2xx MUST contain an offer if the UAS had
   not yet sent an offer.

INVITE要求が申し出を含んで、UASがまだ答えを送らなかったなら、2xxは答えを含まなければなりません。 UASがまだ申し出を送らないで、またINVITEが申し出を含まなかったなら、2xxは申し出を含まなければなりません。

   Once the response has been constructed, it is passed to the INVITE
   server transaction.  Note, however, that the INVITE server
   transaction will be destroyed as soon as it receives this final
   response and passes it to the transport.  Therefore, it is necessary
   to periodically pass the response directly to the transport until the
   ACK arrives.  The 2xx response is passed to the transport with an
   interval that starts at T1 seconds and doubles for each
   retransmission until it reaches T2 seconds (T1 and T2 are defined in
   Section 17).  Response retransmissions cease when an ACK request for
   the response is received.  This is independent of whatever transport
   protocols are used to send the response.

応答がいったん構成されると、それはINVITEサーバ取引に通過されます。 しかしながら、この最終的な応答を受けて、それを輸送に通過するとすぐに、INVITEサーバ取引が破壊されることに注意してください。 したがって、定期的に直接ACKが到着するまでの輸送への応答を通過するのが必要です。 2xx応答は、T1秒からの間隔で輸送に渡されて、T2秒に達するまで(T1とT2はセクション17で定義されます)、各「再-トランスミッション」の代わりをします。 応答を求めるACK要求が受信されているとき、応答「再-トランスミッション」はやみます。 これは応答を送るのに使用されるどんなトランスポート・プロトコルからも独立しています。

Rosenberg, et. al.          Standards Track                    [Page 85]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[85ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      Since 2xx is retransmitted end-to-end, there may be hops between
      UAS and UAC that are UDP.  To ensure reliable delivery across
      these hops, the response is retransmitted periodically even if the
      transport at the UAS is reliable.

2xxが再送された終わりから終わりであるので、UDPであるUASとUACの間には、ホップがあるかもしれません。 これらのホップの向こう側に信頼できる配信を確実にするために、UASの輸送が信頼できても、応答は定期的に再送されます。

   If the server retransmits the 2xx response for 64*T1 seconds without
   receiving an ACK, the dialog is confirmed, but the session SHOULD be
   terminated.  This is accomplished with a BYE, as described in Section
   15.

サーバが64*T1秒の間、受信なしで2xx応答を再送するなら、ACK、対話は確認されて、唯一のセッションはSHOULDです。終えられます。 これはBYEと共にセクション15で説明されるように達成されます。

14 Modifying an Existing Session

14 既存のセッションを変更すること。

   A successful INVITE request (see Section 13) establishes both a
   dialog between two user agents and a session using the offer-answer
   model.  Section 12 explains how to modify an existing dialog using a
   target refresh request (for example, changing the remote target URI
   of the dialog).  This section describes how to modify the actual
   session.  This modification can involve changing addresses or ports,
   adding a media stream, deleting a media stream, and so on.  This is
   accomplished by sending a new INVITE request within the same dialog
   that established the session.  An INVITE request sent within an
   existing dialog is known as a re-INVITE.

うまくいっているINVITE要求(セクション13を見る)は、申し出答えモデルを使用することで2人のユーザエージェントの間の対話とセッションの両方を確立します。 セクション12は、目標を使用することでどう既存の対話を変更するかが要求(例えば、対話のリモート目標URIを変える)をリフレッシュすると説明します。 このセクションは実際のセッションを変更する方法を説明します。 この変更は、メディアの流れなどを削除して、メディアの流れを加えて、アドレスかポートを変えることを伴うことができます。 これは、セッションを確立したのと同じ対話の中で新しいINVITE要求を送ることによって、達成されます。 既存の対話の中で送られたINVITE要求は再INVITEとして知られています。

      Note that a single re-INVITE can modify the dialog and the
      parameters of the session at the same time.

独身の再INVITEが同時にセッションの対話とパラメタを変更できることに注意してください。

   Either the caller or callee can modify an existing session.

訪問者か訪問される人が既存のセッションを変更できます。

   The behavior of a UA on detection of media failure is a matter of
   local policy.  However, automated generation of re-INVITE or BYE is
   NOT RECOMMENDED to avoid flooding the network with traffic when there
   is congestion.  In any case, if these messages are sent
   automatically, they SHOULD be sent after some randomized interval.

メディア失敗の検出のUAの動きはローカルの方針の問題です。 しかしながら、再INVITEかBYEの自動化された世代は混雑があるとき、交通に伴うネットワークをあふれさせるのを避けるNOT RECOMMENDEDです。 どのような場合でも、これらであるなら自動的にメッセージを送って、それらはSHOULDです。いくつかのランダマイズされた間隔の後に送ります。

      Note that the paragraph above refers to automatically generated
      BYEs and re-INVITEs.  If the user hangs up upon media failure, the
      UA would send a BYE request as usual.

上のパラグラフが自動的に発生したBYEsと再INVITEsについて言及することに注意してください。 ユーザがメディア失敗にハングアップするなら、UAはいつものようにBYE要求を送るでしょう。

14.1 UAC Behavior

14.1 UACの振舞い

   The same offer-answer model that applies to session descriptions in
   INVITEs (Section 13.2.1) applies to re-INVITEs.  As a result, a UAC
   that wants to add a media stream, for example, will create a new
   offer that contains this media stream, and send that in an INVITE
   request to its peer.  It is important to note that the full
   description of the session, not just the change, is sent.  This
   supports stateless session processing in various elements, and
   supports failover and recovery capabilities.  Of course, a UAC MAY

INVITEs(セクション13.2.1)のセッション記述に適用するのと同じ申し出答えモデルは再INVITEsに当てはまります。 その結果、例えばメディアの流れを加えたがっているUACはこのメディアの流れを含む新しい申し出を作成して、INVITE要求でそれを同輩に送るでしょう。 変化だけではなく、セッションの余すところのない解説が送られることに注意するのは重要です。 これは、様々な要素で国がないセッション処理を支持して、フェイルオーバーと回復能力を支持します。 もちろんUAC MAY

Rosenberg, et. al.          Standards Track                    [Page 86]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[86ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   send a re-INVITE with no session description, in which case the first
   reliable non-failure response to the re-INVITE will contain the offer
   (in this specification, that is a 2xx response).

セッション記述なしで再INVITEを送ってください。その場合では、再INVITEへの最初の信頼できる非失敗応答は申し出(すなわち、この仕様の2xx応答)を含むでしょう。

   If the session description format has the capability for version
   numbers, the offerer SHOULD indicate that the version of the session
   description has changed.

セッション記述形式にバージョン番号のための能力があるなら、申出人SHOULDは、セッション記述のバージョンが変化したのを示します。

   The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set
   following the same rules as for regular requests within an existing
   dialog, described in Section 12.

To、From、Call-ID CSeq、および再INVITEのRequest-URIは定期的な要求のようにセクション12で説明された既存の対話の中で同じ規則に従うセットです。

   A UAC MAY choose not to add an Alert-Info header field or a body with
   Content-Disposition "alert" to re-INVITEs because UASs do not
   typically alert the user upon reception of a re-INVITE.

UAC MAYは、UASsが再INVITEのレセプションでユーザを通常警告しないのでContent-気質「警戒」でAlert-インフォメーションヘッダーフィールドかボディーを再INVITEsに加えないのを選びます。

   Unlike an INVITE, which can fork, a re-INVITE will never fork, and
   therefore, only ever generate a single final response.  The reason a
   re-INVITE will never fork is that the Request-URI identifies the
   target as the UA instance it established the dialog with, rather than
   identifying an address-of-record for the user.

INVITEと異なって、再INVITEは決して分岐しないで、ただ一つの最終的な応答を発生させるだけでしょう。INVITEは分岐できます。 再INVITEが決して分岐しない理由はRequest-URIが、ユーザのために記録されている住所を特定するより目標がそれが対話を確立したUA例であるとむしろ認識するということです。

   Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.

別のINVITE取引がどちらかの方向に進行している間UAC MUST NOTが対話の中で新しいINVITE取引を開始することに注意してください。

      1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the transaction reaches the completed or terminated
         state before initiating the new INVITE.

1. 進行中のINVITEクライアント取引があれば、新しいINVITEを開始する前に取引が完成したか終えられた状態に達するまで、トゥは待たなければなりません。

      2. If there is an ongoing INVITE server transaction, the TU MUST
         wait until the transaction reaches the confirmed or terminated
         state before initiating the new INVITE.

2. 進行中のINVITEサーバ取引があれば、新しいINVITEを開始する前に取引が確認されたか終えられた状態に達するまで、トゥは待たなければなりません。

   However, a UA MAY initiate a regular transaction while an INVITE
   transaction is in progress.  A UA MAY also initiate an INVITE
   transaction while a regular transaction is in progress.

しかしながら、INVITE取引が進行している間、UA MAYは普通取引を開始します。 また、普通取引が進行している間、UA MAYはINVITE取引を開始します。

   If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been issued.
   Note that, as stated in Section 12.2.1.2, if the non-2xx final
   response is a 481 (Call/Transaction Does Not Exist), or a 408
   (Request Timeout), or no response at all is received for the re-
   INVITE (that is, a timeout is returned by the INVITE client
   transaction), the UAC will terminate the dialog.

UAが再INVITEへの非2xxの最終的な応答を受けるなら、セッションパラメタは変わりがあってはいけません、まるで再INVITEが全く発行されていないかのように。 再INVITE(INVITEクライアント取引ですなわち、タイムアウトを返す)のために、(呼び出し/取引Does Not Exist)にもかかわらず、408(Timeoutを要求する)にもかかわらず、応答が非2xxの最終的な応答が481であるならセクション12.2.1で.2を述べるから全くであるメモを受け取って、UACは対話を終えるでしょう。

Rosenberg, et. al.          Standards Track                    [Page 87]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[87ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
   timer with a value T chosen as follows:

aであるなら、UACは再INVITEへの491応答を受けて、それは値Tが以下の通り選ばれているSHOULDスタートaタイマです:

      1. If the UAC is the owner of the Call-ID of the dialog ID
         (meaning it generated the value), T has a randomly chosen value
         between 2.1 and 4 seconds in units of 10 ms.

1. UACが対話IDのCall-IDの所有者(それを意味すると、値は発生した)であるなら、Tはユニットの10原稿に手当たりしだいに選ばれた値を2.1〜4秒持っています。

      2. If the UAC is not the owner of the Call-ID of the dialog ID, T
         has a randomly chosen value of between 0 and 2 seconds in units
         of 10 ms.

2. UACが対話IDのCall-IDの所有者でないなら、Tには、ユニットの10原稿の0〜2秒の手当たりしだいに選ばれた値があります。

   When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
   if it still desires for that session modification to take place.  For
   example, if the call was already hung up with a BYE, the re-INVITE
   would not take place.

タイマが撃たれると、UAC SHOULDはもう一度再INVITEを試みます、そのセッション変更が行われることをまだ望んでいるなら。 例えば、呼び出しがBYEと共に既に掛けられるなら、再INVITEは行われないでしょうに。

   The rules for transmitting a re-INVITE and for generating an ACK for
   a 2xx response to re-INVITE are the same as for the initial INVITE
   (Section 13.2.1).

再INVITEを伝えて、再INVITEへの2xx応答のためにACKを発生させるための規則は初期のINVITE(セクション13.2.1)のように同じです。

14.2 UAS Behavior

14.2 UASの振舞い

   Section 13.3.1 describes the procedure for distinguishing incoming
   re-INVITEs from incoming initial INVITEs and handling a re-INVITE for
   an existing dialog.

セクション13.3 .1 入って来る初期のINVITEsと入って来る再INVITEsを区別して、既存の対話のために再INVITEを扱うための手順について説明します。

   A UAS that receives a second INVITE before it sends the final
   response to a first INVITE with a lower CSeq sequence number on the
   same dialog MUST return a 500 (Server Internal Error) response to the
   second INVITE and MUST include a Retry-After header field with a
   randomly chosen value of between 0 and 10 seconds.

下側のCSeq一連番号が同じ対話にある状態で最終的な応答を最初のINVITEに送る前に第2のINVITEを受けるUASは第2INVITEへの500(サーバInternal Error)応答を返さなければならなくて、0〜10秒の手当たりしだいに選ばれた値がある後のRetryヘッダーフィールドを含まなければなりません。

   A UAS that receives an INVITE on a dialog while an INVITE it had sent
   on that dialog is in progress MUST return a 491 (Request Pending)
   response to the received INVITE.

それがその対話で送ったINVITEが進行していますが、対話でINVITEを受けるUASは容認されたINVITEへの491(Pendingを要求する)応答を返さなければなりません。

   If a UA receives a re-INVITE for an existing dialog, it MUST check
   any version identifiers in the session description or, if there are
   no version identifiers, the content of the session description to see
   if it has changed.  If the session description has changed, the UAS
   MUST adjust the session parameters accordingly, possibly after asking
   the user for confirmation.

UAが既存の対話のために再INVITEを受けるなら、それは、それが変化したかどうかを見るためにセッション記述におけるどんなバージョン識別子かバージョン識別子が全くないときのセッション記述の内容もチェックしなければなりません。 セッション記述が変化したなら、UAS MUSTはそれに従って、セッションパラメタを調整します、ユーザに確認を求めたことによると後に。

      Versioning of the session description can be used to accommodate
      the capabilities of new arrivals to a conference, add or delete
      media, or change from a unicast to a multicast conference.

ユニキャストからマルチキャスト会議に出生の能力を会議に収容するか、メディアを加えるか、削除する、または変化するのにセッション記述のVersioningを使用できます。

Rosenberg, et. al.          Standards Track                    [Page 88]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[88ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   If the new session description is not acceptable, the UAS can reject
   it by returning a 488 (Not Acceptable Here) response for the re-
   INVITE.  This response SHOULD include a Warning header field.

新しいセッション記述が許容できないなら、UASは、再INVITEのために488(Acceptable Hereでない)応答を返すことによって、それを拒絶できます。 この応答SHOULDはWarningヘッダーフィールドを含んでいます。

   If a UAS generates a 2xx response and never receives an ACK, it
   SHOULD generate a BYE to terminate the dialog.

UASはaであるなら2xx応答を発生させて、ACKを決して受けません、それ。SHOULDは対話を終えるBYEを発生させます。

   A UAS MAY choose not to generate 180 (Ringing) responses for a re-
   INVITE because UACs do not typically render this information to the
   user.  For the same reason, UASs MAY choose not to use an Alert-Info
   header field or a body with Content-Disposition "alert" in responses
   to a re-INVITE.

UAS MAYは、UACsがこの情報をユーザに通常提供しないので再INVITEのために180(鳴る)の応答を発生させないのを選びます。 同じ理由から、UASsは、再INVITEへの応答におけるAlert-インフォメーションヘッダーフィールドかContent-気質「警戒」があるボディーを使用しないのを選ぶかもしれません。

   A UAS providing an offer in a 2xx (because the INVITE did not contain
   an offer) SHOULD construct the offer as if the UAS were making a
   brand new call, subject to the constraints of sending an offer that
   updates an existing session, as described in [13] in the case of SDP.
   Specifically, this means that it SHOULD include as many media formats
   and media types that the UA is willing to support.  The UAS MUST
   ensure that the session description overlaps with its previous
   session description in media formats, transports, or other parameters
   that require support from the peer.  This is to avoid the need for
   the peer to reject the session description.  If, however, it is
   unacceptable to the UAC, the UAC SHOULD generate an answer with a
   valid session description, and then send a BYE to terminate the
   session.

まるでブランドがUASで新しくなっているかのように2xx(INVITEが申し出を含まなかったので)SHOULD構造物の申し出に申し出を提供するUASは既存のセッションをアップデートする申し出を送る規制を条件として呼びます、SDPの場合における[13]で説明されるように。 明確に、これがそれを意味する、それ、SHOULDはUAが支持しても構わないと思っている同じくらい多くのメディア形式とメディアタイプを含んでいます。 UAS MUSTは、セッション記述が同輩から支持を要するメディア形式、輸送、または他のパラメタにおける前のセッション記述に重なるのを確実にします。 これは、同輩がセッション記述を拒絶する必要性を避けるためのものです。 しかしながら、それがUACに容認できないなら、UAC SHOULDは、有効なセッション記述で答えを発生させて、セッションを終えるためにBYEを送ります。

15 Terminating a Session

15 セッションを終えること。

   This section describes the procedures for terminating a session
   established by SIP.  The state of the session and the state of the
   dialog are very closely related.  When a session is initiated with an
   INVITE, each 1xx or 2xx response from a distinct UAS creates a
   dialog, and if that response completes the offer/answer exchange, it
   also creates a session.  As a result, each session is "associated"
   with a single dialog - the one which resulted in its creation.  If an
   initial INVITE generates a non-2xx final response, that terminates
   all sessions (if any) and all dialogs (if any) that were created
   through responses to the request.  By virtue of completing the
   transaction, a non-2xx final response also prevents further sessions
   from being created as a result of the INVITE.  The BYE request is
   used to terminate a specific session or attempted session.  In this
   case, the specific session is the one with the peer UA on the other
   side of the dialog.  When a BYE is received on a dialog, any session
   associated with that dialog SHOULD terminate.  A UA MUST NOT send a
   BYE outside of a dialog.  The caller's UA MAY send a BYE for either
   confirmed or early dialogs, and the callee's UA MAY send a BYE on
   confirmed dialogs, but MUST NOT send a BYE on early dialogs.

このセクションはセッションがSIPで設立した終える手順について説明します。 セッションの州と対話の状態は非常に密接に関係づけられます。 セッションがINVITEと共に開始されるとき、異なったUASからの各1xxか2xx応答が対話を作成します、そして、また、その応答が申し出/答え交換を終了するなら、それはセッションを作成します。 その結果、それぞれのセッションはただ一つの対話に「関連しています」--創造をもたらしたもの。 初期のINVITEが非2xxの最終的な応答を発生させるなら、それは要求への応答で作成されたすべての(もしあれば)のセッションとすべての対話(もしあれば)を終えます。 また、取引を完了することによって、非2xxの最終的な応答は、セッションがINVITEの結果、作成されるのをさらに防ぎます。 BYE要求は、特定のセッションか試みられたセッションを終えるのに使用されます。 この場合、特定のセッションは対話の反対側の上に同輩UAがあるものです。 BYEが対話で受け取られているとき、どんなセッションもSHOULDが終えるその対話と交際しました。 Uaは対話の外にBYEを送ってはいけません。 訪問者のUA MAYは確認されたか早めの対話のためにBYEを送ります、そして、早めの対話にBYEを送ってはいけないのを除いて、訪問される人のUA MAYは確認された対話にBYEを送ります。

Rosenberg, et. al.          Standards Track                    [Page 89]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[89ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   However, the callee's UA MUST NOT send a BYE on a confirmed dialog
   until it has received an ACK for its 2xx response or until the server
   transaction times out.  If no SIP extensions have defined other
   application layer states associated with the dialog, the BYE also
   terminates the dialog.

しかしながら、それが外で2xx応答かサーバ取引回数までACKを受けるまで、訪問される人のUaは確認された対話にBYEを送ってはいけません。 また、どんなSIP拡張子も対話に関連している他の応用層州を定義していないなら、BYEは対話を終えます。

   The impact of a non-2xx final response to INVITE on dialogs and
   sessions makes the use of CANCEL attractive.  The CANCEL attempts to
   force a non-2xx response to the INVITE (in particular, a 487).
   Therefore, if a UAC wishes to give up on its call attempt entirely,
   it can send a CANCEL.  If the INVITE results in 2xx final response(s)
   to the INVITE, this means that a UAS accepted the invitation while
   the CANCEL was in progress.  The UAC MAY continue with the sessions
   established by any 2xx responses, or MAY terminate them with BYE.

対話とセッションでのINVITEへの非2xxの最終的な応答の影響で、キャンセルの使用は魅力的になります。 キャンセルは、INVITE(特に487)への非2xx応答を強制するのを試みます。 したがって、UACが呼び出し試みに完全に見切りをつけたいなら、それはキャンセルを送ることができます。 INVITEがINVITEへの2xxの最終的な応答をもたらすなら、これは、キャンセルが進行していましたが、UASが招待に応じたことを意味します。 UAC MAYがどんな2xx応答でも確立されたセッションを続行するか、またはBYEと共にそれらを終えるかもしれません。

      The notion of "hanging up" is not well defined within SIP.  It is
      specific to a particular, albeit common, user interface.
      Typically, when the user hangs up, it indicates a desire to
      terminate the attempt to establish a session, and to terminate any
      sessions already created.  For the caller's UA, this would imply a
      CANCEL request if the initial INVITE has not generated a final
      response, and a BYE to all confirmed dialogs after a final
      response.  For the callee's UA, it would typically imply a BYE;
      presumably, when the user picked up the phone, a 2xx was
      generated, and so hanging up would result in a BYE after the ACK
      is received.  This does not mean a user cannot hang up before
      receipt of the ACK, it just means that the software in his phone
      needs to maintain state for a short while in order to clean up
      properly.  If the particular UI allows for the user to reject a
      call before its answered, a 403 (Forbidden) is a good way to
      express that.  As per the rules above, a BYE can't be sent.

「ハングアップ」であるという概念はSIPの中でよく定義されません。 それは特定の、そして、それにしても、一般的なユーザーインタフェースに特定です。 ユーザがハングアップするとき、通常、それはセッションを確立して、どんなセッションにも既に作成されていた状態で終わる試みを終える願望を示します。 訪問者のUAに関しては、初期のINVITEが最終的な応答を発生させていなくて、すべてへのBYEが最終的な応答の後に対話を確認するなら、これはキャンセル要求を含意するでしょうに。 訪問される人のUAに関しては、BYEを通常含意するでしょう。 ユーザが電話をしたとき、おそらく、2xxは発生しました、そして、ACKが受け取られていた後にしたがって、ハングアップするのはBYEをもたらすでしょう。 これは、ユーザが以前ACKの領収書を掛けることができないことを意味しないで、それは、彼の電話のソフトウェアが、適切に掃除するために短時間状態を維持する必要をただ意味します。 それが答えられる前に特定のUIが、ユーザが呼び出しを拒絶するのを許容するなら、403(禁じられる)はそれを言い表す早道です。 規則に従って、上に、BYEを送ることができません。

15.1 Terminating a Session with a BYE Request

15.1 不戦勝とのセッションが要求する終わり

15.1.1 UAC Behavior

15.1.1 UACの振舞い

   A BYE request is constructed as would any other request within a
   dialog, as described in Section 12.

BYE要求はいかなる他の要求であるだろうというののようにもセクション12で説明されるように対話の中で構成されます。

   Once the BYE is constructed, the UAC core creates a new non-INVITE
   client transaction, and passes it the BYE request.  The UAC MUST
   consider the session terminated (and therefore stop sending or
   listening for media) as soon as the BYE request is passed to the
   client transaction.  If the response for the BYE is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no

BYEがいったん組み立てられると、UACコアは、新しい非INVITEクライアント取引を作成して、BYE要求にそれに合格します。 BYE要求がクライアント取引に合格されるとすぐに、UAC MUSTは、セッションが終わった(したがって、メディアの送るか、または聞こうとするのを止める)と考えます。 BYEのための応答が481(呼び出し/取引Does Not Exist)、408(Timeoutを要求する)またはノーであるなら

Rosenberg, et. al.          Standards Track                    [Page 90]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[90ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   response at all is received for the BYE (that is, a timeout is
   returned by the client transaction), the UAC MUST consider the
   session and the dialog terminated.

BYEのために全く応答を受けました、そして、(クライアント取引ですなわち、タイムアウトを返します)UAC MUSTはセッションを考えます、そして、対話は終わりました。

15.1.2 UAS Behavior

15.1.2 UASの振舞い

   A UAS first processes the BYE request according to the general UAS
   processing described in Section 8.2.  A UAS core receiving a BYE
   request checks if it matches an existing dialog.  If the BYE does not
   match an existing dialog, the UAS core SHOULD generate a 481
   (Call/Transaction Does Not Exist) response and pass that to the
   server transaction.

セクション8.2で説明された一般的なUAS処理に従って、UASは最初に、BYE要求を処理します。 BYE要求を受け取るUASコアは、それが既存の対話に合っているかどうかチェックします。 BYEが既存の対話に合っていないなら、UASコアSHOULDは481(呼び出し/取引Does Not Exist)応答を発生させて、サーバ取引にそれを通過します。

      This rule means that a BYE sent without tags by a UAC will be
      rejected.  This is a change from RFC 2543, which allowed BYE
      without tags.

この規則は、タグなしでUACによって送られたBYEが拒絶されることを意味します。 これはRFC2543からの変化です。(RFCはタグなしでBYEを許容しました)。

   A UAS core receiving a BYE request for an existing dialog MUST follow
   the procedures of Section 12.2.2 to process the request.  Once done,
   the UAS SHOULD terminate the session (and therefore stop sending and
   listening for media).  The only case where it can elect not to are
   multicast sessions, where participation is possible even if the other
   participant in the dialog has terminated its involvement in the
   session.  Whether or not it ends its participation on the session,
   the UAS core MUST generate a 2xx response to the BYE, and MUST pass
   that to the server transaction for transmission.

既存の対話を求めるBYE要求を受け取るUASコアは、要求を処理するためにセクション12.2.2の手順に従わなければなりません。 いったんすると、UAS SHOULDはセッションを終えます(したがって、メディアを送って、聞こうとするのを止めてください)。 それがそうしないのを選ぶことができる唯一のケースがマルチキャストセッションです。(そこでは、対話のもう片方の関係者がセッションのときにかかわり合いを終えたとしても、参加が可能です)。 それがセッションのときに参加を終わらせるか否かに関係なく、UASコアは、BYEへの2xx応答を発生させなければならなくて、トランスミッションのためのサーバ取引にそれを通過しなければなりません。

   The UAS MUST still respond to any pending requests received for that
   dialog.  It is RECOMMENDED that a 487 (Request Terminated) response
   be generated to those pending requests.

UAS MUSTはまだその対話のために受け取られたどんな未定の要求にも応じています。 487(Terminatedを要求する)応答がそれらの未定の要求に発生するのは、RECOMMENDEDです。

16 Proxy Behavior

16 プロキシの振舞い

16.1 Overview

16.1 概観

   SIP proxies are elements that route SIP requests to user agent
   servers and SIP responses to user agent clients.  A request may
   traverse several proxies on its way to a UAS.  Each will make routing
   decisions, modifying the request before forwarding it to the next
   element.  Responses will route through the same set of proxies
   traversed by the request in the reverse order.

SIPプロキシはルートSIPがユーザエージェントサーバとユーザエージェントのクライアントへのSIP応答に要求する要素です。 要求はいくつかのプロキシをUASへの途中に横断するかもしれません。 それぞれが次の要素にそれを送る前に要求を変更して、ルーティングを決定にするでしょう。 応答は同じくらいを通して逆順における要求で横断されたプロキシのセットを発送するでしょう。

   Being a proxy is a logical role for a SIP element.  When a request
   arrives, an element that can play the role of a proxy first decides
   if it needs to respond to the request on its own.  For instance, the
   request may be malformed or the element may need credentials from the
   client before acting as a proxy.  The element MAY respond with any

プロキシであることはSIP要素のための論理的な役割です。 要求が到着するとき、最初にプロキシの役割を果たすことができる要素は、それが、それ自身のものに関する要求に応じる必要であるかどうか決めます。 例えば、要求が奇形であるかもしれません、または要素はプロキシとして務める前に、クライアントからの信任状を必要とするかもしれません。 要素はいずれでも応じるかもしれません。

Rosenberg, et. al.          Standards Track                    [Page 91]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[91ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   appropriate error code.  When responding directly to a request, the
   element is playing the role of a UAS and MUST behave as described in
   Section 8.2.

エラーコードを当ててください。 直接要求に応じるとき、要素は、UASの役割を果たしていて、セクション8.2で説明されるように反応しなければなりません。

   A proxy can operate in either a stateful or stateless mode for each
   new request.  When stateless, a proxy acts as a simple forwarding
   element.  It forwards each request downstream to a single element
   determined by making a targeting and routing decision based on the
   request.  It simply forwards every response it receives upstream.  A
   stateless proxy discards information about a message once the message
   has been forwarded.  A stateful proxy remembers information
   (specifically, transaction state) about each incoming request and any
   requests it sends as a result of processing the incoming request.  It
   uses this information to affect the processing of future messages
   associated with that request.  A stateful proxy MAY choose to "fork"
   a request, routing it to multiple destinations.  Any request that is
   forwarded to more than one location MUST be handled statefully.

プロキシはそれぞれの新しい要求のためのstatefulか国がないモードのどちらかで働くことができます。 国がないときに、プロキシは簡単な推進要素として務めます。 それは要求に基づく狙いとルーティング決定をすることによって決定しているただ一つの要素に各要求に川下に転送します。 それは単に上流へ受けるあらゆる応答を進めます。 いったんメッセージを転送すると、国がないプロキシはメッセージの情報を捨てます。 statefulプロキシは入って来る要求を処理することの結果、それが送るそれぞれの入って来る要求とどんな要求の情報(明確に取引状態)も覚えています。 それは、その要求に関連している将来のメッセージの処理に影響するのにこの情報を使用します。 複数の目的地にそれを発送して、statefulプロキシは、要求を「分岐させること」を選ぶかもしれません。 statefullyに複数の位置に転送されるどんな要求も扱わなければなりません。

   In some circumstances, a proxy MAY forward requests using stateful
   transports (such as TCP) without being transaction-stateful.  For
   instance, a proxy MAY forward a request from one TCP connection to
   another transaction statelessly as long as it places enough
   information in the message to be able to forward the response down
   the same connection the request arrived on.  Requests forwarded
   between different types of transports where the proxy's TU must take
   an active role in ensuring reliable delivery on one of the transports
   MUST be forwarded transaction statefully.

いくつかの事情では、取引statefulでなくてstateful輸送(TCPなどの)を使用して、プロキシは要求を転送するかもしれません。 例えば、要求が到着した同じ接続の下側に応答を送ることができるメッセージの十分な情報を置く限り、プロキシは国がなく1つのTCP接続から別の取引までの要求を転送するかもしれません。 statefullyに輸送の異なったタイプに間プロキシのTUが輸送の1つのときに信頼できる配信を確実にする際に活動しなければならない転送された要求に取引を送らなければなりません。

   A stateful proxy MAY transition to stateless operation at any time
   during the processing of a request, so long as it did not do anything
   that would otherwise prevent it from being stateless initially
   (forking, for example, or generation of a 100 response).  When
   performing such a transition, all state is simply discarded.  The
   proxy SHOULD NOT initiate a CANCEL request.

いつでも要求の処理の間、国がない操作へのstatefulプロキシ5月の変遷であり、何もしなかった限り、それは、そうでなければ、それに初めは(100応答の例えば、分岐か世代)国がないのを防ぐでしょう。 そのような変化をするとき、すべての状態が単に捨てられます。 プロキシSHOULD NOTはキャンセル要求を開始します。

   Much of the processing involved when acting statelessly or statefully
   for a request is identical.  The next several subsections are written
   from the point of view of a stateful proxy.  The last section calls
   out those places where a stateless proxy behaves differently.

要求に国がないかstatefullyに行動するときかかわる処理の多くが同じです。 次のいくつかの小区分がstatefulプロキシの観点から書かれます。 最後のセクションは国がないプロキシが異なって振る舞うそれらの場所を大声で叫びます。

16.2 Stateful Proxy

16.2 Statefulプロキシ

   When stateful, a proxy is purely a SIP transaction processing engine.
   Its behavior is modeled here in terms of the server and client
   transactions defined in Section 17.  A stateful proxy has a server
   transaction associated with one or more client transactions by a
   higher layer proxy processing component (see figure 3), known as a
   proxy core.  An incoming request is processed by a server

statefulなときに、プロキシは純粋にSIPトランザクション処理エンジンです。 振舞いはここで取引がセクション17で定義したサーバとクライアントに関してモデル化されます。 statefulプロキシはサーバ取引を1つ以上のクライアント取引により高い層のプロキシ処理の部品(3が計算するのがわかる)で関連していて、プロキシコアとして知られるようにします。 入って来る要求はサーバによって処理されます。

Rosenberg, et. al.          Standards Track                    [Page 92]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[92ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   transaction.  Requests from the server transaction are passed to a
   proxy core.  The proxy core determines where to route the request,
   choosing one or more next-hop locations.  An outgoing request for
   each next-hop location is processed by its own associated client
   transaction.  The proxy core collects the responses from the client
   transactions and uses them to send responses to the server
   transaction.

取引。 サーバ取引からの要求はプロキシコアに合格されます。 プロキシコアは、複数の次のホップ位置を選んで、要求をどこに発送するかを決定します。 それぞれの次のホップ位置を求める送信する要求はそれ自身の関連クライアント取引で処理されます。 プロキシコアは、クライアント取引から応答を集めて、サーバ取引に応答を送るのにそれらを使用します。

   A stateful proxy creates a new server transaction for each new
   request received.  Any retransmissions of the request will then be
   handled by that server transaction per Section 17.  The proxy core
   MUST behave as a UAS with respect to sending an immediate provisional
   on that server transaction (such as 100 Trying) as described in
   Section 8.2.6.  Thus, a stateful proxy SHOULD NOT generate 100
   (Trying) responses to non-INVITE requests.

statefulプロキシはそれぞれの新しい要求のための取引が受け取った新しいサーバを作成します。 そして、要求のどんな「再-トランスミッション」もそのセクション17あたりのサーバ取引で扱われるでしょう。 プロキシコアはUASとしてセクション8.2.6で説明されるようにそのサーバ取引(100Tryingなどの)に即座の臨時郵便切手を送ることに関して振る舞わなければなりません。 したがって、statefulプロキシSHOULD NOTは非INVITE要求への100の(試みること)の応答を発生させます。

   This is a model of proxy behavior, not of software.  An
   implementation is free to take any approach that replicates the
   external behavior this model defines.

これはソフトウェアではなく、プロキシの振舞いのモデルです。 実現は無料でこのモデルが定義する外部の振舞いを模写するどんなアプローチも取ることができます。

   For all new requests, including any with unknown methods, an element
   intending to proxy the request MUST:

すべての新しい要求のために、未知の方法でいずれも含んでいて、プロキシに要求を意図する要素は含まなければなりません:

      1. Validate the request (Section 16.3)

1. 要求を有効にしてください。(セクション16.3)

      2. Preprocess routing information (Section 16.4)

2. ルーティング情報を前処理してください。(セクション16.4)

      3. Determine target(s) for the request (Section 16.5)

3. 要求のための目標を決定してください。(セクション16.5)

            +--------------------+
            |                    | +---+
            |                    | | C |
            |                    | | T |
            |                    | +---+
      +---+ |       Proxy        | +---+   CT = Client Transaction
      | S | |  "Higher" Layer    | | C |
      | T | |                    | | T |   ST = Server Transaction
      +---+ |                    | +---+
            |                    | +---+
            |                    | | C |
            |                    | | T |
            |                    | +---+
            +--------------------+

+--------------------+ | | +---+ | | | C| | | | T| | | +---+ +---+ | プロキシ| +---クライアント+ コネチカット=取引| S| | 「より高く」層にしてください。| | C| | T| | | | T| =サーバ第取引+---+ | | +---+ | | +---+ | | | C| | | | T| | | +---+ +--------------------+

               Figure 3: Stateful Proxy Model

図3: Statefulプロキシモデル

Rosenberg, et. al.          Standards Track                    [Page 93]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[93ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      4. Forward the request to each target (Section 16.6)

4. 各目標に要求を転送してください。(セクション16.6)

      5. Process all responses (Section 16.7)

5. すべての応答を処理してください。(セクション16.7)

16.3 Request Validation

16.3 要求合法化

   Before an element can proxy a request, it MUST verify the message's
   validity.  A valid message must pass the following checks:

要素缶のプロキシa要求の前に、それはメッセージの正当性について確かめなければなりません。 有効なメッセージは以下のチェックを通過しなければなりません:

      1. Reasonable Syntax

1. 合理的な構文

      2. URI scheme

2. URI体系

      3. Max-Forwards

3. 前方へマックス

      4. (Optional) Loop Detection

4. (任意)です。 輪の検出

      5. Proxy-Require

5. プロキシで必要です。

      6. Proxy-Authorization

6. プロキシ承認

   If any of these checks fail, the element MUST behave as a user agent
   server (see Section 8.2) and respond with an error code.

これらのチェックのどれかが失敗するなら、要素は、ユーザエージェントサーバ(セクション8.2を見る)として振る舞って、エラーコードで応じなければなりません。

   Notice that a proxy is not required to detect merged requests and
   MUST NOT treat merged requests as an error condition.  The endpoints
   receiving the requests will resolve the merge as described in Section
   8.2.2.2.

プロキシは検出するのに必要でない通知が、要求を合併して、合併している要求をエラー条件として扱ってはいけません。 要求を受け取る終点はセクション8.2.2で.2に説明されるようにマージを決議するでしょう。

   1. Reasonable syntax check

1. 合理的な構文チェック

      The request MUST be well-formed enough to be handled with a server
      transaction.  Any components involved in the remainder of these
      Request Validation steps or the Request Forwarding section MUST be
      well-formed.  Any other components, well-formed or not, SHOULD be
      ignored and remain unchanged when the message is forwarded.  For
      instance, an element would not reject a request because of a
      malformed Date header field.  Likewise, a proxy would not remove a
      malformed Date header field before forwarding a request.

要求はサーバトランザクションで扱われるほど整形式でなければなりません。 これらのRequest ValidationステップかRequest Forwarding部の残りにかかわるどんなコンポーネントも整形式であるに違いありません。 いかなる他のコンポーネントでありも、整形式であり、メッセージを転送するとき、SHOULDは無視されて、変わりがありません。 例えば、要素は奇形のDateヘッダーフィールドで要求を拒絶しないでしょう。 同様に、要求を転送する前に、プロキシは奇形のDateヘッダーフィールドを取り除かないでしょう。

      This protocol is designed to be extended.  Future extensions may
      define new methods and header fields at any time.  An element MUST
      NOT refuse to proxy a request because it contains a method or
      header field it does not know about.

このプロトコルは、広げられるように設計されています。 今後の拡大はいつでも、新しいメソッドとヘッダーフィールドを定義するかもしれません。 知らないメソッドかヘッダーフィールドを含んでいるので、要素はプロキシに要求を拒絶してはいけません。

Rosenberg, et. al.          Standards Track                    [Page 94]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[94ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   2. URI scheme check

2. URI体系チェック

      If the Request-URI has a URI whose scheme is not understood by the
      proxy, the proxy SHOULD reject the request with a 416 (Unsupported
      URI Scheme) response.

Request-URIに体系がプロキシに解釈されないURIがあるなら、プロキシSHOULDは416(サポートされないURI Scheme)応答で要求を拒絶します。

   3. Max-Forwards check

3. 前方へマックスのチェック

      The Max-Forwards header field (Section 20.22) is used to limit the
      number of elements a SIP request can traverse.

前方へマックスヘッダーフィールド(セクション20.22)は、SIP要求が横断できる要素の数を制限するのに使用されます。

      If the request does not contain a Max-Forwards header field, this
      check is passed.

要求が前方へマックスヘッダーフィールドを含んでいないなら、このチェックは通過されます。

      If the request contains a Max-Forwards header field with a field
      value greater than zero, the check is passed.

要求が分野値がゼロより大きい前方へマックスヘッダーフィールドを含んでいるなら、チェックは通過されます。

      If the request contains a Max-Forwards header field with a field
      value of zero (0), the element MUST NOT forward the request.  If
      the request was for OPTIONS, the element MAY act as the final
      recipient and respond per Section 11.  Otherwise, the element MUST
      return a 483 (Too many hops) response.

要求が(0)がない分野値がある前方へマックスヘッダーフィールドを含んでいるなら、要素は要求を転送してはいけません。 要求がOPTIONSのためのものであったなら、要素は、最終的な受取人として機能して、セクション11単位で応じるかもしれません。 さもなければ、要素は483(あまりに多くのホップ)応答を返さなければなりません。

   4. Optional Loop Detection check

4. 任意のLoop Detectionはチェックします。

      An element MAY check for forwarding loops before forwarding a
      request.  If the request contains a Via header field with a sent-
      by value that equals a value placed into previous requests by the
      proxy, the request has been forwarded by this element before.  The
      request has either looped or is legitimately spiraling through the
      element.  To determine if the request has looped, the element MAY
      perform the branch parameter calculation described in Step 8 of
      Section 16.6 on this message and compare it to the parameter
      received in that Via header field.  If the parameters match, the
      request has looped.  If they differ, the request is spiraling, and
      processing continues.  If a loop is detected, the element MAY
      return a 482 (Loop Detected) response.

要求を転送する前に、要素は推進輪がないかどうかチェックするかもしれません。 要求がプロキシによる前に置かれた値と等しい値で送られた要求があるViaヘッダーフィールドを含んでいるなら、以前、この要素で要求を転送したことがあります。 要求は、どちらかを輪にさせるか、または要素を通して合法的にらせん形になっています。 要素は、要求が輪にされたかどうか決定するために、セクション16.6のStep8で説明されたブランチパラメタ計算をこのメッセージに実行して、そのViaヘッダーフィールドで受け取られたパラメタとそれを比較するかもしれません。 パラメタが合っているなら、要求は輪にされました。 彼らが異なるなら、要求はらせん形になっています、そして、処理は続きます。 輪が検出されるなら、要素は482(輪のDetected)応答を返すかもしれません。

   5. Proxy-Require check

5. チェックをプロキシで必要としてください。

      Future extensions to this protocol may introduce features that
      require special handling by proxies.  Endpoints will include a
      Proxy-Require header field in requests that use these features,
      telling the proxy not to process the request unless the feature is
      understood.

このプロトコルへの今後の拡大はプロキシで特別な取り扱いを必要とする特徴を導入するかもしれません。 特徴が理解されない場合、終点はaが、プロキシに言って、これらの特徴を使用する要求におけるヘッダーフィールドが処理しないのをProxy必要とするインクルードに要求を望んでいます。

Rosenberg, et. al.          Standards Track                    [Page 95]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[95ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      If the request contains a Proxy-Require header field (Section
      20.29) with one or more option-tags this element does not
      understand, the element MUST return a 420 (Bad Extension)
      response.  The response MUST include an Unsupported (Section
      20.40) header field listing those option-tags the element did not
      understand.

要求がaを含んでいるなら1があるヘッダーフィールド(セクション20.29)をProxy必要とするか、またはこの要素がするより多くのオプションタグは分かりません、そして、要素は420(悪いExtension)応答を返さなければなりません。 応答は要素が理解していなかったそれらのオプションタグを記載するUnsupported(セクション20.40)ヘッダーフィールドを含まなければなりません。

   6. Proxy-Authorization check

6. プロキシ許可検査

      If an element requires credentials before forwarding a request,
      the request MUST be inspected as described in Section 22.3.  That
      section also defines what the element must do if the inspection
      fails.

要求、要求を転送するのが必要でなければならない前に要素が資格証明書を必要とするなら、セクション22.3で説明されるように、点検されてください。 また、点検が失敗するなら、そのセクションは要素がしなければならないことを定義します。

16.4 Route Information Preprocessing

16.4 経由地案内前処理

   The proxy MUST inspect the Request-URI of the request.  If the
   Request-URI of the request contains a value this proxy previously
   placed into a Record-Route header field (see Section 16.6 item 4),
   the proxy MUST replace the Request-URI in the request with the last
   value from the Route header field, and remove that value from the
   Route header field.  The proxy MUST then proceed as if it received
   this modified request.

プロキシは要求のRequest-URIを点検しなければなりません。 要求のRequest-URIがこのプロキシが以前にRecord-ルートヘッダーフィールドに置いた値を含んでいるなら(セクション16.6項目4を見てください)、プロキシは、要求におけるRequest-URIをRouteヘッダーフィールドから最終値に取り替えて、Routeヘッダーフィールドからその値を移さなければなりません。 そして、まるでこの変更された要求を受け取るかのようにプロキシは続かなければなりません。

      This will only happen when the element sending the request to the
      proxy (which may have been an endpoint) is a strict router.  This
      rewrite on receive is necessary to enable backwards compatibility
      with those elements.  It also allows elements following this
      specification to preserve the Request-URI through strict-routing
      proxies (see Section 12.2.1.1).

プロキシ(終点であったかもしれない)に要求を送る要素が厳しいルータであるときにだけ、これは起こるでしょう。 この書き直し、オンである、受信、後方にそれらの要素との互換性を可能にするために、必要です。 セクション12.2を見てください。また、この仕様に従う要素が厳しいルーティングプロキシを通してそれでRequest-URIを保存できる、(.1 .1)。

      This requirement does not obligate a proxy to keep state in order
      to detect URIs it previously placed in Record-Route header fields.
      Instead, a proxy need only place enough information in those URIs
      to recognize them as values it provided when they later appear.

この要件は、それが以前にRecord-ルートヘッダーフィールドに置いたURIを検出するためにプロキシが状態を維持するのを義務付けません。 後で現れるとき、代わりに、プロキシはそれらのURIにおけるそれらがそれが提供した値であると認めることができるくらいの情報を置くだけでよいです。

   If the Request-URI contains a maddr parameter, the proxy MUST check
   to see if its value is in the set of addresses or domains the proxy
   is configured to be responsible for.  If the Request-URI has a maddr
   parameter with a value the proxy is responsible for, and the request
   was received using the port and transport indicated (explicitly or by
   default) in the Request-URI, the proxy MUST strip the maddr and any
   non-default port or transport parameter and continue processing as if
   those values had not been present in the request.

Request-URIがmaddrパラメタを含んでいるなら、プロキシは、アドレスかドメインのセットに値があるならプロキシが責任があるように構成されていることを確認するためにチェックしなければなりません。 Request-URIにはプロキシは責任がある値があるmaddrパラメタがあって、Request-URIで示された(明らかかデフォルトで)ポートと輸送を使用することで要求を受け取ったなら、プロキシは、どんなmaddrと非デフォルトポートや輸送パラメタも剥取って、まるでそれらの値が要求に存在していなかったかのように処理し続けなければなりません。

Rosenberg, et. al.          Standards Track                    [Page 96]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[96ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      A request may arrive with a maddr matching the proxy, but on a
      port or transport different from that indicated in the URI.  Such
      a request needs to be forwarded to the proxy using the indicated
      port and transport.

要求はポート、または、URIで示されたそれと異なったプロキシに合っているmaddrにもかかわらず、輸送の上に到着するかもしれません。 そのような要求は、示されたポートと輸送を使用することでプロキシに送られる必要があります。

   If the first value in the Route header field indicates this proxy,
   the proxy MUST remove that value from the request.

Routeヘッダーフィールドにおける最初の値がこのプロキシを示すなら、プロキシは要求からその値を取り除かなければなりません。

16.5 Determining Request Targets

16.5 要求目標を決定すること。

   Next, the proxy calculates the target(s) of the request.  The set of
   targets will either be predetermined by the contents of the request
   or will be obtained from an abstract location service.  Each target
   in the set is represented as a URI.

次に、プロキシは要求の目標について計算します。 目標のセットを要求のコンテンツで予定するか、または抽象的な位置のサービスから入手するでしょう。 セットにおける各目標はURIとして表されます。

   If the Request-URI of the request contains an maddr parameter, the
   Request-URI MUST be placed into the target set as the only target
   URI, and the proxy MUST proceed to Section 16.6.

要求のRequest-URIがmaddrパラメタを含んでいるなら、唯一の目標URIとしてRequest-URIを目標セットに置かなければなりません、そして、プロキシはセクション16.6に続かなければなりません。

   If the domain of the Request-URI indicates a domain this element is
   not responsible for, the Request-URI MUST be placed into the target
   set as the only target, and the element MUST proceed to the task of
   Request Forwarding (Section 16.6).

Request-URIのドメインがこの要素が原因とならないドメインを示すなら、唯一の目標としてRequest-URIを目標セットに置かなければなりません、そして、要素はRequest Forwarding(セクション16.6)に関するタスクに続かなければなりません。

      There are many circumstances in which a proxy might receive a
      request for a domain it is not responsible for.  A firewall proxy
      handling outgoing calls (the way HTTP proxies handle outgoing
      requests) is an example of where this is likely to occur.

プロキシがそれは責任がないドメインを求める要求を受け取るかもしれない多くの事情があります。 発信電話(HTTPプロキシが送信する要求を扱う方法)を扱っているファイアウォールプロキシはこれが起こりそうであるところに関する例です。

   If the target set for the request has not been predetermined as
   described above, this implies that the element is responsible for the
   domain in the Request-URI, and the element MAY use whatever mechanism
   it desires to determine where to send the request.  Any of these
   mechanisms can be modeled as accessing an abstract Location Service.
   This may consist of obtaining information from a location service
   created by a SIP Registrar, reading a database, consulting a presence
   server, utilizing other protocols, or simply performing an
   algorithmic substitution on the Request-URI.  When accessing the
   location service constructed by a registrar, the Request-URI MUST
   first be canonicalized as described in Section 10.3 before being used
   as an index.  The output of these mechanisms is used to construct the
   target set.

要求に設定された目標が上で説明されるように予定されていないなら、これは、要素がRequest-URIにおけるドメインに原因となるのを含意します、そして、要素はそれが要求をどこに送るかを決定することを望んでいるどんなメカニズムも使用するかもしれません。 抽象的なLocation Serviceにアクセスするとしてこれらのメカニズムのいずれもモデル化できます。 これはSIP Registrarによって作成された位置のサービスからの獲得情報から成るかもしれません、データベースを読んで、存在サーバに相談して、他のプロトコルを利用するか、または単にRequest-URIにアルゴリズムの代替を実行して。 記録係によって構成された位置のサービスにアクセスするとき、Request-URIとして、インデックスとして使用される前にセクション10.3で説明されて、最初に、canonicalizedしなければなりません。 これらのメカニズムの出力は、目標セットを構成するのに使用されます。

   If the Request-URI does not provide sufficient information for the
   proxy to determine the target set, it SHOULD return a 485 (Ambiguous)
   response.  This response SHOULD contain a Contact header field
   containing URIs of new addresses to be tried.  For example, an INVITE

Request-URIがプロキシが決定する十分な情報を提供しないなら、目標はセットして、それはSHOULDリターンa485(あいまいな)応答です。 この応答SHOULDは試みられるべき新しいアドレスのURIを含むContactヘッダーフィールドを含んでいます。 例えば、INVITE

Rosenberg, et. al.          Standards Track                    [Page 97]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[97ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   to sip:John.Smith@company.com may be ambiguous at a proxy whose
   location service has multiple John Smiths listed.  See Section
   21.4.23 for details.

一口に: John.Smith@company.com は位置のサービスで複数のジョン・スミスを記載するプロキシであいまいであるかもしれません。 詳細に関してセクション21.4.23を見てください。

   Any information in or about the request or the current environment of
   the element MAY be used in the construction of the target set.  For
   instance, different sets may be constructed depending on contents or
   the presence of header fields and bodies, the time of day of the
   request's arrival, the interface on which the request arrived,
   failure of previous requests, or even the element's current level of
   utilization.

要求か要求のどんな情報か要素の現在の環境も目標セットの構造に使用されるかもしれません。 例えば、ヘッダーフィールドとボディーのコンテンツか存在によって、異なったセットは構成されるかもしれません、要求の到着の時刻、要求が到着したインタフェース、前の要求、または要素の現在のレベルさえの利用の失敗。

   As potential targets are located through these services, their URIs
   are added to the target set.  Targets can only be placed in the
   target set once.  If a target URI is already present in the set
   (based on the definition of equality for the URI type), it MUST NOT
   be added again.

仮想ターゲットがこれらのサービスで見つけられているとき、それらのURIは目標セットに追加されます。 一度目標セットに目標を置くことができるだけです。 目標URIがセット(URIタイプのための平等の定義に基づいている)で既に存在しているなら、再びそれを加えてはいけません。

   A proxy MUST NOT add additional targets to the target set if the
   Request-URI of the original request does not indicate a resource this
   proxy is responsible for.

オリジナルの要求のRequest-URIがこのプロキシは責任があるリソースを示さないなら、プロキシが追加目標を目標セットに追加してはいけません。

      A proxy can only change the Request-URI of a request during
      forwarding if it is responsible for that URI.  If the proxy is not
      responsible for that URI, it will not recurse on 3xx or 416
      responses as described below.

それはそのURIに責任がある場合にだけ、プロキシが推進の間、要求のRequest-URIを変えることができます。 プロキシはそのURIに責任がないと、それが3xxか416の応答のときに以下で説明されるように「再-呪」われないでしょう。

   If the Request-URI of the original request indicates a resource this
   proxy is responsible for, the proxy MAY continue to add targets to
   the set after beginning Request Forwarding.  It MAY use any
   information obtained during that processing to determine new targets.
   For instance, a proxy may choose to incorporate contacts obtained in
   a redirect response (3xx) into the target set.  If a proxy uses a
   dynamic source of information while building the target set (for
   instance, if it consults a SIP Registrar), it SHOULD monitor that
   source for the duration of processing the request.  New locations
   SHOULD be added to the target set as they become available.  As
   above, any given URI MUST NOT be added to the set more than once.

オリジナルの要求のRequest-URIがこのプロキシは責任があるリソースを示すなら、プロキシが、Request Forwardingを始めた後に目標をセットに追加し続けるかもしれません。 それは新しい目標を決定するためにその処理の間に得られたどんな情報も使用するかもしれません。 例えば、プロキシは、再直接の応答(3xx)で得られた接触を目標セットに取り入れるのを選ぶかもしれません。 プロキシが目標セットを造っている間、情報のダイナミックな源を使用する、(例えば、それがSIP Registrarに相談する、)、それ、SHOULDは要求を処理する持続時間のためにそのソースをモニターします。 目標セットに追加されるようになりますが、新しい位置のSHOULDはそうです。利用可能。 同じくらい上では、どんな与えられたURIも一度より多くのセットに追加してはいけません。

      Allowing a URI to be added to the set only once reduces
      unnecessary network traffic, and in the case of incorporating
      contacts from redirect requests prevents infinite recursion.

URIが一度だけセットに追加されるのを許容するのが、不要なネットワークトラフィックを減少させて、再直接の要求からの接触を取り入れる場合で無限の再帰を防ぎます。

   For example, a trivial location service is a "no-op", where the
   target URI is equal to the incoming request URI.  The request is sent
   to a specific next hop proxy for further processing.  During request

例えば、些細な位置のサービスは目標URIが入って来る要求URIと等しい「オプアートがありません」です。 さらなる処理のために次期特定のホッププロキシに要求を送ります。 要求の間

Rosenberg, et. al.          Standards Track                    [Page 98]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[98ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   forwarding of Section 16.6, Item 6, the identity of that next hop,
   expressed as a SIP or SIPS URI, is inserted as the top-most Route
   header field value into the request.

セクション16.6の推進、Item6(SIPかSIPS URIとして言い表されたその次のホップのアイデンティティ)は最も最高Routeヘッダーフィールド価値として要求に挿入されます。

   If the Request-URI indicates a resource at this proxy that does not
   exist, the proxy MUST return a 404 (Not Found) response.

Request-URIが存在しないこのプロキシでリソースを示すなら、プロキシは404(Foundでない)応答を返さなければなりません。

   If the target set remains empty after applying all of the above, the
   proxy MUST return an error response, which SHOULD be the 480
   (Temporarily Unavailable) response.

上記のすべてを適用するプロキシが誤り応答を返さなければならなかった後に残りが空にする目標セット、どのSHOULDが480歳であるか、(一時的である、Unavailable) 応答。

16.6 Request Forwarding

16.6 要求推進

   As soon as the target set is non-empty, a proxy MAY begin forwarding
   the request.  A stateful proxy MAY process the set in any order.  It
   MAY process multiple targets serially, allowing each client
   transaction to complete before starting the next.  It MAY start
   client transactions with every target in parallel.  It also MAY
   arbitrarily divide the set into groups, processing the groups
   serially and processing the targets in each group in parallel.

目標セットが非空であるとすぐに、プロキシは、要求を転送し始めるかもしれません。 statefulプロキシは順不同なセットを処理するかもしれません。 それは順次マルチターゲットを処理するかもしれなくて、許容は次を始める前に完了するそれぞれのクライアント取引です。 あらゆる目標が平行な状態でそれはクライアントトランザクションを始めるかもしれません。 また、それは任意にセットをグループに分割するかもしれません、順次、グループを処理して、平行なそれぞれのグループで目標を処理して。

   A common ordering mechanism is to use the qvalue parameter of targets
   obtained from Contact header fields (see Section 20.10).  Targets are
   processed from highest qvalue to lowest.  Targets with equal qvalues
   may be processed in parallel.

一般的な注文メカニズムはContactヘッダーフィールドから入手された目標のqvalueパラメタを使用する(セクション20.10を見てください)ことです。 目標は最も高いqvalueから最も低いqvalueまで処理されます。 等しいqvaluesがある目標は平行に処理されるかもしれません。

   A stateful proxy must have a mechanism to maintain the target set as
   responses are received and associate the responses to each forwarded
   request with the original request.  For the purposes of this model,
   this mechanism is a "response context" created by the proxy layer
   before forwarding the first request.

statefulプロキシは、応答が受け取られているので目標がセットしたと主張するメカニズムを持って、それぞれの転送された要求への応答をオリジナルの要求に関連づけなければなりません。 このモデルの目的のために、このメカニズムは最初の要求を転送する前にプロキシ層によって作成された「応答文脈」です。

   For each target, the proxy forwards the request following these
   steps:

各目標のために、これらの方法に従って、プロキシは要求を転送します:

      1.  Make a copy of the received request

1. 受信された要求のコピーを作ってください。

      2.  Update the Request-URI

2. 要求URIをアップデートしてください。

      3.  Update the Max-Forwards header field

3. 前方へマックスヘッダーフィールドをアップデートしてください。

      4.  Optionally add a Record-route header field value

4. 任意にRecord-ルートヘッダーフィールド価値を高めてください。

      5.  Optionally add additional header fields

5. 任意に追加ヘッダーフィールドを加えてください。

      6.  Postprocess routing information

6. ルーティング情報を後処理してください。

      7.  Determine the next-hop address, port, and transport

7. 次のホップアドレス、ポート、および輸送を決定してください。

Rosenberg, et. al.          Standards Track                    [Page 99]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[99ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      8.  Add a Via header field value

8. Viaヘッダーフィールド価値を高めてください。

      9.  Add a Content-Length header field if necessary

9. 必要なら、Content-長さのヘッダーフィールドを加えてください。

      10. Forward the new request

10. 新しい要求を転送してください。

      11. Set timer C

11. タイマCを設定してください。

   Each of these steps is detailed below:

それぞれのこれらのステップは以下で詳細です:

      1. Copy request

1. コピー要求

         The proxy starts with a copy of the received request.  The copy
         MUST initially contain all of the header fields from the
         received request.  Fields not detailed in the processing
         described below MUST NOT be removed.  The copy SHOULD maintain
         the ordering of the header fields as in the received request.
         The proxy MUST NOT reorder field values with a common field
         name (See Section 7.3.1).  The proxy MUST NOT add to, modify,
         or remove the message body.

プロキシは受信された要求のコピーから始まります。 コピーは初めは、受信された要求からのヘッダーフィールドのすべてを含まなければなりません。 以下で説明された処理で詳しく述べられなかった野原を取り除いてはいけません。 コピーSHOULDは受信された要求のようにヘッダーフィールドの注文を維持します。 プロキシは共同耕地名(セクション7.3.1を見る)があるNOT追加注文分野値がそうしなければなりません。 プロキシが加えてはいけない、メッセージ本体を変更するか、または取り除いてください。

         An actual implementation need not perform a copy; the primary
         requirement is that the processing for each next hop begin with
         the same request.

実際の実装はコピーを実行する必要はありません。 プライマリ要件は次の各ホップのための処理が同じ要求で始まるということです。

      2. Request-URI

2. 要求URI

         The Request-URI in the copy's start line MUST be replaced with
         the URI for this target.  If the URI contains any parameters
         not allowed in a Request-URI, they MUST be removed.

この目標のためにコピーのスタート系列におけるRequest-URIをURIに取り替えなければなりません。 URIが何かRequest-URIで許容されなかったパラメタを含んでいるなら、それらを取り除かなければなりません。

         This is the essence of a proxy's role.  This is the mechanism
         through which a proxy routes a request toward its destination.

これはプロキシの役割の本質です。 これはプロキシが目的地に向かって要求を発送するメカニズムです。

         In some circumstances, the received Request-URI is placed into
         the target set without being modified.  For that target, the
         replacement above is effectively a no-op.

いくつかの事情では、変更されないで、容認されたRequest-URIは目標セットに置かれます。 その目標のために、事実上、上の交換はオプアートではありません。

      3. Max-Forwards

3. 前方へマックス

         If the copy contains a Max-Forwards header field, the proxy
         MUST decrement its value by one (1).

コピーが前方へマックスヘッダーフィールドを含んでいるなら、プロキシは値を1つ(1)減少させなければなりません。

         If the copy does not contain a Max-Forwards header field, the
         proxy MUST add one with a field value, which SHOULD be 70.

コピーが前方へマックスヘッダーフィールドを含んでいないなら、プロキシは、分野値がある1、どのSHOULDが70歳であるかと言い足さなければなりません。

         Some existing UAs will not provide a Max-Forwards header field
         in a request.

いくつかの既存のUAsは要求で前方へマックスにヘッダーフィールドを提供しないでしょう。

Rosenberg, et. al.          Standards Track                   [Page 100]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[100ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      4. Record-Route

4. 記録的なルート

         If this proxy wishes to remain on the path of future requests
         in a dialog created by this request (assuming the request
         creates a dialog), it MUST insert a Record-Route header field
         value into the copy before any existing Record-Route header
         field values, even if a Route header field is already present.

このプロキシがこの要求で作成された対話における今後の要求の経路に残りたいと思うなら(要求を仮定すると、対話は作成されます)、どんな既存のRecord-ルートヘッダーフィールド値の前にもRecord-ルートヘッダーフィールド価値をコピーに挿入しなければなりません、Routeヘッダーフィールドが既に存在していても。

         Requests establishing a dialog may contain a preloaded Route
         header field.

対話を確立する要求はプレロードされたRouteヘッダーフィールドを含むかもしれません。

         If this request is already part of a dialog, the proxy SHOULD
         insert a Record-Route header field value if it wishes to remain
         on the path of future requests in the dialog.  In normal
         endpoint operation as described in Section 12, these Record-
         Route header field values will not have any effect on the route
         sets used by the endpoints.

この要求が既に対話の一部であるなら、対話における今後の要求の経路に残りたいと思うなら、プロキシSHOULDはRecord-ルートヘッダーフィールド価値を挿入します。 セクション12で説明される通常の終点操作では、これらのRecordルートヘッダーフィールド値で、終点でルートセットへのどんな効果も使用しないでしょう。

         The proxy will remain on the path if it chooses to not insert a
         Record-Route header field value into requests that are already
         part of a dialog.  However, it would be removed from the path
         when an endpoint that has failed reconstitutes the dialog.

Record-ルートヘッダーフィールド価値を既に対話の一部である要求に挿入しないのを選ぶと、プロキシは経路に留まるでしょう。 しかしながら、失敗した終点が対話を再編成するとき、経路からそれを取り除くでしょう。

         A proxy MAY insert a Record-Route header field value into any
         request.  If the request does not initiate a dialog, the
         endpoints will ignore the value.  See Section 12 for details on
         how endpoints use the Record-Route header field values to
         construct Route header fields.

プロキシはRecord-ルートヘッダーフィールド価値をどんな要求にも挿入するかもしれません。 要求が対話を開始しないと、終点は値を無視するでしょう。 終点がRouteヘッダーフィールドを構成するのにどうRecord-ルートヘッダーフィールド値を使用するかに関する詳細に関してセクション12を見てください。

         Each proxy in the path of a request chooses whether to add a
         Record-Route header field value independently - the presence of
         a Record-Route header field in a request does not obligate this
         proxy to add a value.

要求の経路の各プロキシは、独自にRecord-ルートヘッダーフィールド価値を高めるかどうかを選びます--要求における、Record-ルートヘッダーフィールドの存在は、このプロキシが価値を高めるのを義務付けません。

         The URI placed in the Record-Route header field value MUST be a
         SIP or SIPS URI.  This URI MUST contain an lr parameter (see
         Section 19.1.1).  This URI MAY be different for each
         destination the request is forwarded to.  The URI SHOULD NOT
         contain the transport parameter unless the proxy has knowledge
         (such as in a private network) that the next downstream element
         that will be in the path of subsequent requests supports that
         transport.

Record-ルートヘッダーフィールド価値に置かれたURIは、SIPかSIPS URIであるに違いありません。 このURIはlrパラメタを含まなければなりません(セクション19.1.1を見てください)。 要求が転送される各目的地において、このURIは異なっているかもしれません。 プロキシにその後の要求の経路にある次の下流要素がその輸送をサポートするという知識(私設のネットワークなどの)がない場合、URI SHOULD NOTは輸送パラメタを含んでいます。

         The URI this proxy provides will be used by some other element
         to make a routing decision.  This proxy, in general, has no way
         of knowing the capabilities of that element, so it must
         restrict itself to the mandatory elements of a SIP
         implementation: SIP URIs and either the TCP or UDP transports.

このプロキシが提供するURIはある他の要素によって使用されて、ルーティング決定をするでしょう。 このプロキシにはその要素の能力を知る方法が全く一般にないので、それ自体をSIP実装の義務的な要素に制限しなければなりません: TCPかUDPが輸送するSIP URIとどちらか。

Rosenberg, et. al.          Standards Track                   [Page 101]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[101ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         The URI placed in the Record-Route header field MUST resolve to
         the element inserting it (or a suitable stand-in) when the
         server location procedures of [4] are applied to it, so that
         subsequent requests reach the same SIP element.  If the
         Request-URI contains a SIPS URI, or the topmost Route header
         field value (after the post processing of bullet 6) contains a
         SIPS URI, the URI placed into the Record-Route header field
         MUST be a SIPS URI.  Furthermore, if the request was not
         received over TLS, the proxy MUST insert a Record-Route header
         field.  In a similar fashion, a proxy that receives a request
         over TLS, but generates a request without a SIPS URI in the
         Request-URI or topmost Route header field value (after the post
         processing of bullet 6), MUST insert a Record-Route header
         field that is not a SIPS URI.

Record-ルートヘッダーフィールドに置かれたURIは、[4]の位置決め手順がそれに適用されるとサーバであるときにそれ(または、適当な代役)を挿入する要素に決議しなければなりません、その後の要求が同じSIP要素に達するように。 Request-URIがSIPS URIを含んでいるか、または最上のRouteヘッダーフィールド価値(弾丸6の後工程の後の)がSIPS URIを含んでいるなら、Record-ルートヘッダーフィールドに置かれたURIはSIPS URIであるに違いありません。 その上、要求がTLSの上に受け取られなかったなら、プロキシはRecord-ルートヘッダーフィールドを挿入しなければなりません。 同様に、SIPS URIなしでRequest-URIか最上のRouteヘッダーフィールド価値(弾丸6の後工程の後の)でTLSの上に要求を受け取りますが、要求を生成するプロキシはSIPS URIでないRecord-ルートヘッダーフィールドを挿入しなければなりません。

         A proxy at a security perimeter must remain on the perimeter
         throughout the dialog.

セキュリティ周辺のプロキシは対話中に周辺に留まらなければなりません。

         If the URI placed in the Record-Route header field needs to be
         rewritten when it passes back through in a response, the URI
         MUST be distinct enough to locate at that time.  (The request
         may spiral through this proxy, resulting in more than one
         Record-Route header field value being added).  Item 8 of
         Section 16.7 recommends a mechanism to make the URI
         sufficiently distinct.

Record-ルートヘッダーフィールドに置かれたURIが、応答で通り抜けて戻るとき、書き直される必要があるなら、URIはその時場所を見つけるほど異なっていなければなりません。 (高められる1つ以上のRecord-ルートヘッダーフィールド価値をもたらして、要求はこのプロキシを通してらせん形になるかもしれません。) セクション16.7の項目8は、メカニズムでURIが十分異なるようになることを勧めます。

         The proxy MAY include parameters in the Record-Route header
         field value.  These will be echoed in some responses to the
         request such as the 200 (OK) responses to INVITE.  Such
         parameters may be useful for keeping state in the message
         rather than the proxy.

プロキシはRecord-ルートヘッダーフィールド価値でパラメタを入れるかもしれません。 これらはINVITEへの200(OK)の応答などの要求へのいくつかの応答で反響されるでしょう。 そのようなパラメタはプロキシよりむしろメッセージに状態を維持することの役に立つかもしれません。

         If a proxy needs to be in the path of any type of dialog (such
         as one straddling a firewall), it SHOULD add a Record-Route
         header field value to every request with a method it does not
         understand since that method may have dialog semantics.

プロキシは、どんなタイプの対話(1としてのファイアウォールにまたがるそのようなもの)の経路にもある必要があります、それ。そのメソッドには対話意味論があるかもしれないので、SHOULDはそれが理解していないメソッドでRecord-ルートヘッダーフィールド価値をあらゆる要求に高めます。

         The URI a proxy places into a Record-Route header field is only
         valid for the lifetime of any dialog created by the transaction
         in which it occurs.  A dialog-stateful proxy, for example, MAY
         refuse to accept future requests with that value in the
         Request-URI after the dialog has terminated.  Non-dialog-
         stateful proxies, of course, have no concept of when the dialog
         has terminated, but they MAY encode enough information in the
         value to compare it against the dialog identifier of future
         requests and MAY reject requests not matching that information.
         Endpoints MUST NOT use a URI obtained from a Record-Route
         header field outside the dialog in which it was provided.  See

プロキシがRecord-ルートヘッダーフィールドに置くURIは単にそれが起こるトランザクションによって作成されたどんな対話の生涯も、有効です。 例えば、対話-statefulプロキシは、対話が終わった後にRequest-URIにおけるその値で今後の要求を受け入れるのを拒否するかもしれません。 非、-対話statefulなプロキシには対話が終わった時に関する概念が全くもちろんありませんが、彼らは、値における今後の要求に関する対話識別子に対してそれを比較できるくらいの情報をコード化して、その情報に合っていない要求を拒絶するかもしれません。 終点はRecord-ルートヘッダーフィールドから対話で外それが提供された得られたURIを使用してはいけません。 見てください。

Rosenberg, et. al.          Standards Track                   [Page 102]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[102ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         Section 12 for more information on an endpoint's use of
         Record-Route header fields.

Record-ルートヘッダーフィールドの終点の使用に関する詳しい情報のためのセクション12。

         Record-routing may be required by certain services where the
         proxy needs to observe all messages in a dialog.  However, it
         slows down processing and impairs scalability and thus proxies
         should only record-route if required for a particular service.

プロキシが、対話におけるすべてのメッセージを観測する必要があるところで記録的なルーティングが、あるサービスで必要であるかもしれません。 しかしながら、処理を減速させて、スケーラビリティを損ないます、そして、その結果、プロキシは必要なら特定のサービスのために記録的なルートで損なうだけであるべきです。

         The Record-Route process is designed to work for any SIP
         request that initiates a dialog.  INVITE is the only such
         request in this specification, but extensions to the protocol
         MAY define others.

Record-ルートプロセスは、対話を開始するどんなSIP要求のためにも働くように設計されています。 INVITEはそのようなものがこの仕様で要求する唯一ですが、プロトコルへの拡大は他のものを定義するかもしれません。

      5. Add Additional Header Fields

5. 追加ヘッダーフィールドを加えてください。

         The proxy MAY add any other appropriate header fields to the
         copy at this point.

プロキシはここにいかなる他の適切なヘッダーフィールドもコピーに加えるかもしれません。

      6. Postprocess routing information

6. ルーティング情報を後処理してください。

         A proxy MAY have a local policy that mandates that a request
         visit a specific set of proxies before being delivered to the
         destination.  A proxy MUST ensure that all such proxies are
         loose routers.  Generally, this can only be known with
         certainty if the proxies are within the same administrative
         domain.  This set of proxies is represented by a set of URIs
         (each of which contains the lr parameter).  This set MUST be
         pushed into the Route header field of the copy ahead of any
         existing values, if present.  If the Route header field is
         absent, it MUST be added, containing that list of URIs.

プロキシには、送付先に提供される前に要求が特定のプロキシを訪問するのを強制するローカルの方針があるかもしれません。 プロキシは、そのようなすべてのプロキシがゆるいルータであることを保証しなければなりません。 一般に、同じ管理ドメインの中にプロキシがある場合にだけ、確実性でこれを知ることができます。 1セットのURI(それのそれぞれがlrパラメタを含む)によってこのセットのプロキシは代理をされます。 このセットは、どんな既存の値の前にもコピーのRouteヘッダーフィールドに押されて、存在していなければなりません。 Routeヘッダーフィールドが欠けるなら、URIのそのリストを含んでいて、それを加えなければなりません。

         If the proxy has a local policy that mandates that the request
         visit one specific proxy, an alternative to pushing a Route
         value into the Route header field is to bypass the forwarding
         logic of item 10 below, and instead just send the request to
         the address, port, and transport for that specific proxy.  If
         the request has a Route header field, this alternative MUST NOT
         be used unless it is known that next hop proxy is a loose
         router.  Otherwise, this approach MAY be used, but the Route
         insertion mechanism above is preferred for its robustness,
         flexibility, generality and consistency of operation.
         Furthermore, if the Request-URI contains a SIPS URI, TLS MUST
         be used to communicate with that proxy.

プロキシにローカルの方針があるならそれが、要求が1つの特定のプロキシを訪問するのを強制して、RouteヘッダーフィールドにRoute値を押し込むことへの代替手段は、その特定のプロキシのためのアドレス、ポート、および輸送に下で項目10の推進論理を迂回させて、代わりにただ要求を送ることです。 要求でRouteヘッダーフィールドがあって、次期ホッププロキシがゆるいルータであることが知られていない場合、この代替手段を使用してはいけません。 さもなければ、このアプローチは使用されるかもしれませんが、上のRoute挿入メカニズムは操作の丈夫さ、柔軟性、一般性、および一貫性のために好まれます。 Request-URIはSIPS URI、TLS MUSTを含んでいます。その上、使用されて、そのプロキシとコミュニケートしてください。

         If the copy contains a Route header field, the proxy MUST
         inspect the URI in its first value.  If that URI does not
         contain an lr parameter, the proxy MUST modify the copy as
         follows:

コピーがRouteヘッダーフィールドを含んでいるなら、プロキシは最初の値におけるURIを点検しなければなりません。 そのURIがlrパラメタを含んでいないなら、プロキシは以下のコピーを変更しなければなりません:

Rosenberg, et. al.          Standards Track                   [Page 103]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[103ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         -  The proxy MUST place the Request-URI into the Route header
            field as the last value.

- プロキシは最終値としてRequest-URIをRouteヘッダーフィールドに置かなければなりません。

         -  The proxy MUST then place the first Route header field value
            into the Request-URI and remove that value from the Route
            header field.

- プロキシは、次に、最初のRouteヘッダーフィールド価値をRequest-URIに置いて、Routeヘッダーフィールドからその値を移さなければなりません。

         Appending the Request-URI to the Route header field is part of
         a mechanism used to pass the information in that Request-URI
         through strict-routing elements.  "Popping" the first Route
         header field value into the Request-URI formats the message the
         way a strict-routing element expects to receive it (with its
         own URI in the Request-URI and the next location to visit in
         the first Route header field value).

Request-URIをRouteヘッダーフィールドに追加するのは、厳しいルーティング要素を通したそのRequest-URIにおける情報を通過するのに使用されるメカニズムの一部です。 最初のRouteヘッダーフィールド価値をRequest-URIに「飛び出させる」と、メッセージは厳しいルーティング要素がそれ(それ自身のURIがRequest-URIと最初のRouteヘッダーフィールド価値で訪問する次の位置にある)を受けると予想する方法でフォーマットされます。

      7. Determine Next-Hop Address, Port, and Transport

7. 次のホップアドレス、ポート、および輸送を決定してください。

         The proxy MAY have a local policy to send the request to a
         specific IP address, port, and transport, independent of the
         values of the Route and Request-URI.  Such a policy MUST NOT be
         used if the proxy is not certain that the IP address, port, and
         transport correspond to a server that is a loose router.
         However, this mechanism for sending the request through a
         specific next hop is NOT RECOMMENDED; instead a Route header
         field should be used for that purpose as described above.

プロキシには、特定のIPアドレス、ポート、および輸送に要求を送るローカルの方針があるかもしれません、RouteとRequest-URIの値から、独立しています。 プロキシがIPアドレス、ポート、および輸送がゆるいルータであるサーバに一致しているのを確信していないなら、そのような方針を使用してはいけません。 しかしながら、次の特定のホップを通して要求を送るためのこのメカニズムはNOT RECOMMENDEDです。 代わりに、Routeヘッダーフィールドはそのために上で説明されるように使用されるべきです。

         In the absence of such an overriding mechanism, the proxy
         applies the procedures listed in [4] as follows to determine
         where to send the request.  If the proxy has reformatted the
         request to send to a strict-routing element as described in
         step 6 above, the proxy MUST apply those procedures to the
         Request-URI of the request.  Otherwise, the proxy MUST apply
         the procedures to the first value in the Route header field, if
         present, else the Request-URI.  The procedures will produce an
         ordered set of (address, port, transport) tuples.
         Independently of which URI is being used as input to the
         procedures of [4], if the Request-URI specifies a SIPS
         resource, the proxy MUST follow the procedures of [4] as if the
         input URI were a SIPS URI.

そのような最優先のメカニズムがないとき、プロキシは要求をどこに送るかを決定するためには以下の通りの[4]に記載された手順を適用します。 プロキシがステップ6で説明されるように厳しいルーティング要素に発信するという要求を再フォーマットしたなら、上では、プロキシが要求のRequest-URIにそれらの手順を適用しなければなりません。 さもなければ、プロキシはRouteヘッダーフィールドにおける最初の値に手順を適用しなければなりません、存在しているならほかです。Request-URI。 手順は(アドレス、ポート、輸送)tuplesの1つの順序集合を生産するでしょう。 Request-URIがSIPSリソースを指定するならどのURIが[4]の手順に入力されるように使用されているかの如何にかかわらず、プロキシはまるで入力URIがSIPS URIであるかのように[4]の手順に従わなければなりません。

         As described in [4], the proxy MUST attempt to deliver the
         message to the first tuple in that set, and proceed through the
         set in order until the delivery attempt succeeds.

[4]で説明されるように、プロキシは、設定されるので最初のtupleにメッセージを提供するのを試みなければなりません、そして、配送試みが成功するまで、セットを通して整然とした状態で続いてください。

         For each tuple attempted, the proxy MUST format the message as
         appropriate for the tuple and send the request using a new
         client transaction as detailed in steps 8 through 10.

tupleが試みたそれぞれに関しては、ステップ8〜10で詳しく述べられるように新しいクライアントトランザクションを使用して、プロキシは、tupleのために適宜メッセージをフォーマットして、要求を送らなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 104]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[104ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         Since each attempt uses a new client transaction, it represents
         a new branch.  Thus, the branch parameter provided with the Via
         header field inserted in step 8 MUST be different for each
         attempt.

各試みが新しいクライアントトランザクションを使用するので、それは新しいブランチを代表します。 したがって、各試みにおいて、ステップ8に挿入されたViaヘッダーフィールドが提供されたブランチパラメタは異なっているに違いありません。

         If the client transaction reports failure to send the request
         or a timeout from its state machine, the proxy continues to the
         next address in that ordered set.  If the ordered set is
         exhausted, the request cannot be forwarded to this element in
         the target set.  The proxy does not need to place anything in
         the response context, but otherwise acts as if this element of
         the target set returned a 408 (Request Timeout) final response.

クライアントトランザクションが州のマシンから要求かタイムアウトを送らないことを報告するなら、設定されるよう命令されるので、プロキシは次のアドレスに続きます。 順序集合が疲れ果てるなら、目標セットにおけるこの要素に要求を転送できません。 プロキシは応答文脈に何も置く必要はありませんが、まるで目標のこの要素がセットするかのようにそうでなければ、行為は408(Timeoutを要求する)の最終的な応答を返しました。

      8. Add a Via header field value

8. Viaヘッダーフィールド価値を高めてください。

         The proxy MUST insert a Via header field value into the copy
         before the existing Via header field values.  The construction
         of this value follows the same guidelines of Section 8.1.1.7.
         This implies that the proxy will compute its own branch
         parameter, which will be globally unique for that branch, and
         contain the requisite magic cookie. Note that this implies that
         the branch parameter will be different for different instances
         of a spiraled or looped request through a proxy.

プロキシは既存のViaヘッダーフィールド値の前にViaヘッダーフィールド価値をコピーに挿入しなければなりません。 この価値の工事は.7にセクション8.1.1の同じガイドラインに従います。 これは、プロキシがそのブランチにグローバルにユニークになるそれ自身のブランチパラメタを計算して、必要な魔法のクッキーを含むのを含意します。 これが、ブランチパラメタがプロキシを通してらせん状に動かされたか輪にされた要求の異なったインスタンスにおいて異なるようになるのを含意することに注意してください。

         Proxies choosing to detect loops have an additional constraint
         in the value they use for construction of the branch parameter.
         A proxy choosing to detect loops SHOULD create a branch
         parameter separable into two parts by the implementation.  The
         first part MUST satisfy the constraints of Section 8.1.1.7 as
         described above.  The second is used to perform loop detection
         and distinguish loops from spirals.

輪を検出するのを選ぶプロキシがそれらがブランチパラメタの工事に使用する値における追加規制を持っています。 輪のSHOULDを検出するのを選ぶプロキシは実装で2つの部品に分離できた状態でブランチパラメタを作成します。 最初の部分はセクション8.1の規制を満たさなければなりません。.1 .7 上で説明されるとして。 2番目は、輪の検出を実行して、らせんと輪を区別するのに使用されます。

         Loop detection is performed by verifying that, when a request
         returns to a proxy, those fields having an impact on the
         processing of the request have not changed.  The value placed
         in this part of the branch parameter SHOULD reflect all of
         those fields (including any Route, Proxy-Require and Proxy-
         Authorization header fields).  This is to ensure that if the
         request is routed back to the proxy and one of those fields
         changes, it is treated as a spiral and not a loop (see Section
         16.3).  A common way to create this value is to compute a
         cryptographic hash of the To tag, From tag, Call-ID header
         field, the Request-URI of the request received (before
         translation), the topmost Via header, and the sequence number
         from the CSeq header field, in addition to any Proxy-Require
         and Proxy-Authorization header fields that may be present.  The

要求がプロキシに戻るとき、要求の処理に影響を与えるそれらの分野が変化していないことを確かめることによって、輪の検出は実行されます。 そして、ブランチパラメタSHOULDのこの部分に置かれた値がそれらの分野のすべてを反映する、(どんなRouteも含んでいる、Proxy必要である、Proxy承認ヘッダーフィールド) これは、要求がプロキシに発送して戻されて、それらの分野の1つが変化するなら、それが輪ではなく、らせんとして扱われるのを保証する(セクション16.3を見る)ためのものです。 この値を作成する一般的な方法はToタグの暗号のハッシュを計算することです、Fromタグ、要求のRequest-URIが、いずれもに加えた最上のViaヘッダー、およびCSeqヘッダーフィールドからの一連番号がProxy必要であり、Proxy-承認ヘッダーがさばくのを受けた(翻訳の前に)存在するかもしれないCall-IDヘッダーフィールド。 The

Rosenberg, et. al.          Standards Track                   [Page 105]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[105ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         algorithm used to compute the hash is implementation-dependent,
         but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a
         reasonable choice.  (Base64 is not permissible for a token.)

ハッシュを計算するのに使用されるアルゴリズムは実装扶養家族、しかし、MD5です。(16進で言い表されたRFC1321[35])は正当な選択です。 (トークンにおいて、Base64は許されていません。)

         If a proxy wishes to detect loops, the "branch" parameter it
         supplies MUST depend on all information affecting processing of
         a request, including the incoming Request-URI and any header
         fields affecting the request's admission or routing.  This is
         necessary to distinguish looped requests from requests whose
         routing parameters have changed before returning to this
         server.

プロキシが輪を検出したいと思うなら、それが提供する「ブランチ」パラメタを要求の処理に影響するすべての情報に依存しなければなりません、入って来るRequest-URIと要求の入場かルーティングに影響するどんなヘッダーフィールドも含んでいて。 これが、ルーティングパラメタがこのサーバに戻る前に変化した要求と輪にされた要求を区別するのに必要です。

         The request method MUST NOT be included in the calculation of
         the branch parameter.  In particular, CANCEL and ACK requests
         (for non-2xx responses) MUST have the same branch value as the
         corresponding request they cancel or acknowledge.  The branch
         parameter is used in correlating those requests at the server
         handling them (see Sections 17.2.3 and 9.2).

ブランチパラメタの計算に要求メソッドを含んではいけません。 キャンセルとACK要求(非2xx応答のための)には、特に、彼らが中止するか、または承諾する対応する要求と同じブランチ値がなければなりません。 ブランチパラメタはそれらを扱うサーバでそれらの要求を関連させる際に使用されます(セクション17.2 .3と9.2を見てください)。

      9. Add a Content-Length header field if necessary

9. 必要なら、Content-長さのヘッダーフィールドを加えてください。

         If the request will be sent to the next hop using a stream-
         based transport and the copy contains no Content-Length header
         field, the proxy MUST insert one with the correct value for the
         body of the request (see Section 20.14).

ストリームのベースの輸送を使用することで次のホップに要求を送って、コピーがContent-長さのヘッダーフィールドを全く含んでいないなら、プロキシは要求のボディーのために正しい値で1つを挿入しなければなりません(セクション20.14を見てください)。

      10. Forward Request

10. 前進の要求

         A stateful proxy MUST create a new client transaction for this
         request as described in Section 17.1 and instructs the
         transaction to send the request using the address, port and
         transport determined in step 7.

statefulプロキシは、この要求のためにセクション17.1で説明されるように新しいクライアントトランザクションを作成しなければならなくて、要求を送るようトランザクションにステップ7で決定しているアドレス、ポート、および輸送を使用することで命令します。

      11. Set timer C

11. タイマCを設定してください。

         In order to handle the case where an INVITE request never
         generates a final response, the TU uses a timer which is called
         timer C.  Timer C MUST be set for each client transaction when
         an INVITE request is proxied.  The timer MUST be larger than 3
         minutes.  Section 16.7 bullet 2 discusses how this timer is
         updated with provisional responses, and Section 16.8 discusses
         processing when it fires.

INVITE要求がproxiedされるとき、INVITE要求が最終的な応答を決して生成しないで、TUがタイマを使用するケースを扱うために、どれがタイマC.Timer Cと呼ばれるかそれぞれのクライアントトランザクションに設定しなければなりません。 タイマは3分より大きいに違いありません。 セクション16.7弾丸2は暫定的な応答でどうこのタイマをアップデートするかについて議論します、そして、セクション16.8は発火するとき、処理するのを議論します。

Rosenberg, et. al.          Standards Track                   [Page 106]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[106ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

16.7 Response Processing

16.7 応答処理

   When a response is received by an element, it first tries to locate a
   client transaction (Section 17.1.3) matching the response.  If none
   is found, the element MUST process the response (even if it is an
   informational response) as a stateless proxy (described below).  If a
   match is found, the response is handed to the client transaction.

要素で応答を受けるとき、それは、最初に、応答に合いながら、クライアントトランザクション(セクション17.1.3)の場所を見つけようとします。 なにも見つけられないなら、要素は状態がないプロキシ(以下で、説明される)として応答(それが情報の応答であっても)を処理しなければなりません。 マッチが見つけられるなら、応答はクライアントトランザクションに手渡されます。

      Forwarding responses for which a client transaction (or more
      generally any knowledge of having sent an associated request) is
      not found improves robustness.  In particular, it ensures that
      "late" 2xx responses to INVITE requests are forwarded properly.

クライアントトランザクション(または、有に関する一般にどんな知識も関連要求を送った以上)が見つけられない応答を進めると、丈夫さは改良されます。 特に、それは、INVITE要求への「遅い」2xx応答が適切に進められるのを確実にします。

   As client transactions pass responses to the proxy layer, the
   following processing MUST take place:

クライアントトランザクションがプロキシ層への応答を通過するのに従って、以下の処理は行われなければなりません:

      1.  Find the appropriate response context

1. 適切な応答関係を見つけてください。

      2.  Update timer C for provisional responses

2. 暫定的な応答のためにタイマCをアップデートしてください。

      3.  Remove the topmost Via

3. 最上のViaを取り外してください。

      4.  Add the response to the response context

4. 応答文脈に応答を追加してください。

      5.  Check to see if this response should be forwarded immediately

5. チェックして、この応答がすぐに進められるべきであるかどうかを見てください。

      6.  When necessary, choose the best final response from the
          response context

6. 必要であることで、応答文脈から最も良い最終的な応答を選んでくださいという場合

   If no final response has been forwarded after every client
   transaction associated with the response context has been terminated,
   the proxy must choose and forward the "best" response from those it
   has seen so far.

応答文脈に関連しているあらゆるクライアントトランザクションを終えた後にどんな最終的な応答も進めていないなら、プロキシは、それが今までのところ見たものから「最も良い」応答を選んで、進めなければなりません。

   The following processing MUST be performed on each response that is
   forwarded.  It is likely that more than one response to each request
   will be forwarded: at least each provisional and one final response.

進められる各応答に以下の処理を実行しなければなりません。 それぞれ要求する1つ以上の応答を進めそうでしょう: 少なくともそれぞれの暫定的、そして、1つの最終的な応答。

      7.  Aggregate authorization header field values if necessary

7. 必要なら、承認ヘッダーフィールド値に集めてください。

      8.  Optionally rewrite Record-Route header field values

8. 任意にRecord-ルートヘッダーフィールド値を書き直してください。

      9.  Forward the response

9. 応答を進めてください。

      10. Generate any necessary CANCEL requests

10. どんな必要なキャンセルも要求であると生成してください。

Rosenberg, et. al.          Standards Track                   [Page 107]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[107ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Each of the above steps are detailed below:

それぞれの上のステップは以下で詳細です:

      1.  Find Context

1. 文脈を見つけてください。

         The proxy locates the "response context" it created before
         forwarding the original request using the key described in
         Section 16.6.  The remaining processing steps take place in
         this context.

プロキシはセクション16.6で説明されたキーを使用することでオリジナルの要求を転送する前にそれが作成した「応答文脈」の場所を見つけます。 残っている処理ステップはこのような関係においては行われます。

      2.  Update timer C for provisional responses

2. 暫定的な応答のためにタイマCをアップデートしてください。

         For an INVITE transaction, if the response is a provisional
         response with status codes 101 to 199 inclusive (i.e., anything
         but 100), the proxy MUST reset timer C for that client
         transaction.  The timer MAY be reset to a different value, but
         this value MUST be greater than 3 minutes.

INVITEトランザクションのために、プロキシは応答がステータスコード101〜199が包括的の暫定的な応答(すなわち、100以外の何でも)であるなら、そのクライアントトランザクションのためのリセットタイマCが応答でなければなりません。 タイマは異価にリセットされるかもしれませんが、この値は3分以上でなければなりません。

      3.  Via

3. via

         The proxy removes the topmost Via header field value from the
         response.

プロキシは応答から最上のViaヘッダーフィールド価値を取り除きます。

         If no Via header field values remain in the response, the
         response was meant for this element and MUST NOT be forwarded.
         The remainder of the processing described in this section is
         not performed on this message, the UAC processing rules
         described in Section 8.1.3 are followed instead (transport
         layer processing has already occurred).

Viaヘッダーフィールド値が全く応答に残っていないなら、応答をこの要素のために意味して、進めてはいけません。 このセクションで説明された処理の残りはこのメッセージに実行されないで、セクション8.1.3で説明されたUAC処理規則は代わりに従われています(トランスポート層処理は既に起こりました)。

         This will happen, for instance, when the element generates
         CANCEL requests as described in Section 10.

例えば、要素がセクション10で説明されるようにキャンセル要求を生成すると、これは起こるでしょう。

      4.  Add response to context

4. 応答を文脈に追加してください。

         Final responses received are stored in the response context
         until a final response is generated on the server transaction
         associated with this context.  The response may be a candidate
         for the best final response to be returned on that server
         transaction.  Information from this response may be needed in
         forming the best response, even if this response is not chosen.

最終的な応答がこの文脈に関連しているサーバトランザクションで生成されるまで、受けられた最終的な応答は応答文脈に保存されます。 応答はそのサーバトランザクションで返される中で最終的な応答最も良い候補であるかもしれません。 この応答からの情報がこの応答が選ばれないでも最も良い応答を形成するのにおいて必要であるかもしれません。

         If the proxy chooses to recurse on any contacts in a 3xx
         response by adding them to the target set, it MUST remove them
         from the response before adding the response to the response
         context.  However, a proxy SHOULD NOT recurse to a non-SIPS URI
         if the Request-URI of the original request was a SIPS URI.  If

プロキシが目標セットにそれらを追加することによって3xx応答におけるどんな接触の「再-呪い」にも選ぶなら、応答文脈に応答を追加する前に、それは応答からそれらを取り除かなければなりません。 しかしながら、オリジナルの要求のRequest-URIであるなら、非SIPS URIのプロキシSHOULD NOT「再-呪い」はSIPS URIでした。 if

Rosenberg, et. al.          Standards Track                   [Page 108]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[108ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         the proxy recurses on all of the contacts in a 3xx response,
         the proxy SHOULD NOT add the resulting contactless response to
         the response context.

3xx応答における接触のすべてのプロキシ「再-呪い」、プロキシSHOULD NOTは結果として起こる非接触応答を応答文脈に追加します。

         Removing the contact before adding the response to the response
         context prevents the next element upstream from retrying a
         location this proxy has already attempted.

応答文脈に応答を追加する前に接触を取り除くのは、次の要素上流がこのプロキシが既に試みた位置を再試行するのを防ぎます。

         3xx responses may contain a mixture of SIP, SIPS, and non-SIP
         URIs.  A proxy may choose to recurse on the SIP and SIPS URIs
         and place the remainder into the response context to be
         returned, potentially in the final response.

3xx応答はSIP、SIPS、および非SIP URIの混合物を含むかもしれません。 プロキシは、SIPとSIPS URIの「再-呪い」に選んで、最終的な応答で潜在的に返される応答文脈に残りを置くかもしれません。

         If a proxy receives a 416 (Unsupported URI Scheme) response to
         a request whose Request-URI scheme was not SIP, but the scheme
         in the original received request was SIP or SIPS (that is, the
         proxy changed the scheme from SIP or SIPS to something else
         when it proxied a request), the proxy SHOULD add a new URI to
         the target set.  This URI SHOULD be a SIP URI version of the
         non-SIP URI that was just tried.  In the case of the tel URL,
         this is accomplished by placing the telephone-subscriber part
         of the tel URL into the user part of the SIP URI, and setting
         the hostpart to the domain where the prior request was sent.
         See Section 19.1.6 for more detail on forming SIP URIs from tel
         URLs.

オリジナルの受信された要求における体系がプロキシがRequest-URI体系がSIPでなかった要求への416(サポートされないURI Scheme)応答を受けますが、SIPかSIPS(要求をproxiedしたとき、すなわち、プロキシは体系をSIPかSIPSから他の何かに変えた)であったなら、プロキシSHOULDは、目標への新しいURIがセットしたと言い足します。 このURI SHOULD、ただ試みられた非SIP URIのSIP URIバージョンになってください。 tel URLの場合では、これは、tel URLの電話加入者部分をSIP URIのユーザ部分に置いて、先の要求が送られたドメインにhostpartを設定することによって、達成されます。 tel URLからSIP URIを形成することに関するその他の詳細に関してセクション19.1.6を見てください。

         As with a 3xx response, if a proxy "recurses" on the 416 by
         trying a SIP or SIPS URI instead, the 416 response SHOULD NOT
         be added to the response context.

3xx応答による416応答代わりにSIPかSIPS URIを試みるのによる416のプロキシ"「再-呪い」"であるならSHOULD NOTとして、応答文脈に追加されてください。

      5.  Check response for forwarding

5. 推進のための応答をチェックしてください。

         Until a final response has been sent on the server transaction,
         the following responses MUST be forwarded immediately:

すぐに、サーバトランザクションで最終的な応答を送るまで以下の応答を進めなければなりません:

         -  Any provisional response other than 100 (Trying)

- 100以外のどんな暫定的な応答(トライ)

         -  Any 2xx response

- どんな2xx応答

         If a 6xx response is received, it is not immediately forwarded,
         but the stateful proxy SHOULD cancel all client pending
         transactions as described in Section 10, and it MUST NOT create
         any new branches in this context.

statefulプロキシSHOULDはトランザクションまでセクション10で説明されるようにすべてのクライアントを取り消します、そして、6xx応答が受け取られているなら、すぐに、進められませんが、それはこのような関係においてはどんな新しいブランチも創設してはいけません。

         This is a change from RFC 2543, which mandated that the proxy
         was to forward the 6xx response immediately.  For an INVITE
         transaction, this approach had the problem that a 2xx response
         could arrive on another branch, in which case the proxy would

これはRFC2543からの変化です。(RFCは、プロキシがすぐに6xx応答を進めることになっているのを強制しました)。 このアプローチには、INVITEトランザクションのために、2xx応答が別のブランチで到着できたという問題がありました、プロキシがそうするどの場合に

Rosenberg, et. al.          Standards Track                   [Page 109]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[109ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         have to forward the 2xx.  The result was that the UAC could
         receive a 6xx response followed by a 2xx response, which should
         never be allowed to happen.  Under the new rules, upon
         receiving a 6xx, a proxy will issue a CANCEL request, which
         will generally result in 487 responses from all outstanding
         client transactions, and then at that point the 6xx is
         forwarded upstream.

2xxを進めるために、持っています。 結果はUACが決して起こることができないべきである2xx応答があとに続いた6xx応答を受けることができたということでした。 新しい規則の下では、6xxを受けるときプロキシはキャンセル要求を出すでしょう、そして、次に、その時、上流へ6xxを進めます。(一般に、要求はすべての傑出しているクライアントトランザクションからの487の応答をもたらすでしょう)。

         After a final response has been sent on the server transaction,
         the following responses MUST be forwarded immediately:

サーバトランザクションで最終的な応答を送った後に、すぐに、以下の応答を進めなければなりません:

         -  Any 2xx response to an INVITE request

- INVITE要求へのどんな2xx応答

         A stateful proxy MUST NOT immediately forward any other
         responses.  In particular, a stateful proxy MUST NOT forward
         any 100 (Trying) response.  Those responses that are candidates
         for forwarding later as the "best" response have been gathered
         as described in step "Add Response to Context".

statefulプロキシはすぐに、いかなる他の応答も進めてはいけません。 特に、statefulプロキシは少しの100の(試みること)の応答も進めてはいけません。 「応答を文脈に追加してください」というステップで説明されるように後で「最も良い」応答として推進の候補であるそれらの応答を集めてあります。

         Any response chosen for immediate forwarding MUST be processed
         as described in steps "Aggregate Authorization Header Field
         Values" through "Record-Route".

即座の推進に選ばれたどんな応答としても、「記録的なルート」で「集合承認ヘッダーフィールド値」というステップで説明されていた状態で処理しなければなりません。

         This step, combined with the next, ensures that a stateful
         proxy will forward exactly one final response to a non-INVITE
         request, and either exactly one non-2xx response or one or more
         2xx responses to an INVITE request.

この次に結合したステップはstatefulプロキシがまさに1つの最終的な応答を非INVITE要求に送って、まさに1つの非2xx応答か1つ以上の2xx応答のどちらかをINVITE要求への送りのようになるのを確実にします。

      6.  Choosing the best response

6. 最も良い応答を選びます。

         A stateful proxy MUST send a final response to a response
         context's server transaction if no final responses have been
         immediately forwarded by the above rules and all client
         transactions in this response context have been terminated.

すぐに、上の規則でどんな最終的な応答も進めていなくて、この応答文脈のすべてのクライアントトランザクションを終えたなら、statefulプロキシは応答文脈のサーバトランザクションに最終的な応答を送らなければなりません。

         The stateful proxy MUST choose the "best" final response among
         those received and stored in the response context.

statefulプロキシは応答文脈に受け取られて、保存されたもので最終的な「最も良い」応答を選ばなければなりません。

         If there are no final responses in the context, the proxy MUST
         send a 408 (Request Timeout) response to the server
         transaction.

文脈にどんな最終的な応答もなければ、プロキシは408(Timeoutを要求する)応答をサーバトランザクションに送らなければなりません。

         Otherwise, the proxy MUST forward a response from the responses
         stored in the response context.  It MUST choose from the 6xx
         class responses if any exist in the context.  If no 6xx class
         responses are present, the proxy SHOULD choose from the lowest
         response class stored in the response context.  The proxy MAY
         select any response within that chosen class.  The proxy SHOULD

さもなければ、プロキシは応答文脈に保存された応答から応答を進めなければなりません。 それは、6xxクラス応答から何かが文脈に存在するかどうかを選ばなければなりません。 どんな6xxクラス応答も存在していないなら、プロキシSHOULDは応答文脈に保存される中で最も低い応答のクラスから選びます。 プロキシはクラスに選ばれたそれの中のどんな応答も選択するかもしれません。 プロキシSHOULD

Rosenberg, et. al.          Standards Track                   [Page 110]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[110ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         give preference to responses that provide information affecting
         resubmission of this request, such as 401, 407, 415, 420, and
         484 if the 4xx class is chosen.

4xxのクラスが選ばれているなら401や、407や、415や、420や、484などのこの要求の再服従に影響する情報を提供する応答に優先を与えてください。

         A proxy which receives a 503 (Service Unavailable) response
         SHOULD NOT forward it upstream unless it can determine that any
         subsequent requests it might proxy will also generate a 503.
         In other words, forwarding a 503 means that the proxy knows it
         cannot service any requests, not just the one for the Request-
         URI in the request which generated the 503.  If the only
         response that was received is a 503, the proxy SHOULD generate
         a 500 response and forward that upstream.

それを決定できないならSHOULD NOTが上流へそれを送る503(サービスUnavailable)応答を受けるAプロキシ、いくらか、その後、また意志がa503を生成するプロキシがそうするかもしれないよう要求します。 言い換えれば、プロキシが知っている503の手段を進めて、それは503を生成した要求におけるRequest URIのためにものだけではなく、どんな要求も修理できません。 受けられた唯一の応答が503であるなら、プロキシSHOULDは500応答を生成して、その上流を進めます。

         The forwarded response MUST be processed as described in steps
         "Aggregate Authorization Header Field Values" through "Record-
         Route".

応答を処理しなければならない進めるのはステップで「記録ルート」で「集合承認ヘッダーフィールド値」について説明しました。

         For example, if a proxy forwarded a request to 4 locations, and
         received 503, 407, 501, and 404 responses, it may choose to
         forward the 407 (Proxy Authentication Required) response.

例えば、プロキシが4つの位置に要求を転送して、503、407、501、および404の応答を受け取ったなら、それは、407(プロキシAuthentication Required)応答を進めるのを選ぶかもしれません。

         1xx and 2xx responses may be involved in the establishment of
         dialogs.  When a request does not contain a To tag, the To tag
         in the response is used by the UAC to distinguish multiple
         responses to a dialog creating request.  A proxy MUST NOT
         insert a tag into the To header field of a 1xx or 2xx response
         if the request did not contain one.  A proxy MUST NOT modify
         the tag in the To header field of a 1xx or 2xx response.

1xxと2xx応答は対話の確立にかかわるかもしれません。 要求がToタグを含まないとき、応答におけるToタグは、要求を作成する対話への複数の応答を区別するのにUACによって使用されます。 要求が1つを含まなかったなら、プロキシは1xxか2xx応答のToヘッダーフィールドにタグを挿入してはいけません。 プロキシは1xxか2xx応答のToヘッダーフィールドでタグを変更してはいけません。

         Since a proxy may not insert a tag into the To header field of
         a 1xx response to a request that did not contain one, it cannot
         issue non-100 provisional responses on its own.  However, it
         can branch the request to a UAS sharing the same element as the
         proxy.  This UAS can return its own provisional responses,
         entering into an early dialog with the initiator of the
         request.  The UAS does not have to be a discreet process from
         the proxy.  It could be a virtual UAS implemented in the same
         code space as the proxy.

プロキシが1つを含まなかった要求への1xx応答のToヘッダーフィールドにタグを挿入しないかもしれないので、それはそれ自身のところで非100の暫定的な応答を発行できません。 しかしながら、それは分岐できます。プロキシと同じ要素を共有するUASへの要求。 要求の創始者と共に早めの対話に入って、このUASはそれ自身の暫定的な応答を返すことができます。 UASはプロキシからの慎重なプロセスである必要はありません。 それはプロキシと同じコードスペースで実装された仮想のUASであるかもしれません。

         3-6xx responses are delivered hop-by-hop.  When issuing a 3-6xx
         response, the element is effectively acting as a UAS, issuing
         its own response, usually based on the responses received from
         downstream elements.  An element SHOULD preserve the To tag
         when simply forwarding a 3-6xx response to a request that did
         not contain a To tag.

3-6 xx応答はホップごとに提供されます。 3-6xx応答を発行するとき、それ自身の応答を発行して、通常、応答に基づいているUASが下流要素から受信したので、事実上、要素は作用しています。 単にToタグを含まなかった要求への3-6xx応答を進めるときToがタグ付けをする要素SHOULD保護区。

         A proxy MUST NOT modify the To tag in any forwarded response to
         a request that contains a To tag.

プロキシはToタグを含む要求へのどんな進められた応答でもToタグを変更してはいけません。

Rosenberg, et. al.          Standards Track                   [Page 111]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[111ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         While it makes no difference to the upstream elements if the
         proxy replaced the To tag in a forwarded 3-6xx response,
         preserving the original tag may assist with debugging.

プロキシが進められた3-6xx応答でToタグを取り替えたかどうかは上流の要素に重要でない間、オリジナルのタグを保存すると、デバッグが助けられるかもしれません。

         When the proxy is aggregating information from several
         responses, choosing a To tag from among them is arbitrary, and
         generating a new To tag may make debugging easier.  This
         happens, for instance, when combining 401 (Unauthorized) and
         407 (Proxy Authentication Required) challenges, or combining
         Contact values from unencrypted and unauthenticated 3xx
         responses.

プロキシがいくつかの応答から情報に集めているとき、それらからToタグを選ぶのは任意です、そして、新しいToタグを生成するのに、デバッグは、より簡単になるかもしれません。 例えば、401(権限のない)と407(プロキシAuthentication Required)の挑戦を結合するか、または非暗号化されるのとunauthenticated 3xx応答からContact値を結合するとき、これは起こります。

      7.  Aggregate Authorization Header Field Values

7. 集合承認ヘッダーフィールド値

         If the selected response is a 401 (Unauthorized) or 407 (Proxy
         Authentication Required), the proxy MUST collect any WWW-
         Authenticate and Proxy-Authenticate header field values from
         all other 401 (Unauthorized) and 407 (Proxy Authentication
         Required) responses received so far in this response context
         and add them to this response without modification before
         forwarding.  The resulting 401 (Unauthorized) or 407 (Proxy
         Authentication Required) response could have several WWW-
         Authenticate AND Proxy-Authenticate header field values.

選択された応答が401(権限のない)か407(プロキシAuthentication Required)であるなら、プロキシは、推進の前にWWWが認証するいずれかも集めて、他のすべての401(権限のない)からのヘッダーフィールド値と今までのところこの応答文脈で受けられている407(プロキシAuthentication Required)の応答をProxy認証して、変更なしでこの応答にそれらを加えなければなりません。 結果として起こる401(権限のない)か407(プロキシAuthentication Required)応答が、数個WWWがヘッダーフィールド値を認証して、Proxy認証するのをさせるかもしれません。

         This is necessary because any or all of the destinations the
         request was forwarded to may have requested credentials.  The
         client needs to receive all of those challenges and supply
         credentials for each of them when it retries the request.
         Motivation for this behavior is provided in Section 26.

要求が転送された目的地のいずれかすべてが資格証明書を要求したかもしれないので、これが必要です。 クライアントは、要求を再試行するとき、それぞれのそれらのためにそれらの挑戦と供給資格証明書のすべてを受ける必要があります。 この振舞いに関する動機をセクション26に提供します。

      8.  Record-Route

8. 記録的なルート

         If the selected response contains a Record-Route header field
         value originally provided by this proxy, the proxy MAY choose
         to rewrite the value before forwarding the response.  This
         allows the proxy to provide different URIs for itself to the
         next upstream and downstream elements.  A proxy may choose to
         use this mechanism for any reason.  For instance, it is useful
         for multi-homed hosts.

選択された応答が元々このプロキシによって提供されたRecord-ルートヘッダーフィールド価値を含んでいるなら、プロキシは、応答を進める前に値を書き直すのを選ぶかもしれません。 これで、プロキシはそれ自体のための異なったURIを次の上流と下流要素に供給できます。 プロキシは、どんな理由にもこのメカニズムを使用するのを選ぶかもしれません。 例えば、それが役に立つ、マルチ、家へ帰り、ホスト。

         If the proxy received the request over TLS, and sent it out
         over a non-TLS connection, the proxy MUST rewrite the URI in
         the Record-Route header field to be a SIPS URI.  If the proxy
         received the request over a non-TLS connection, and sent it out
         over TLS, the proxy MUST rewrite the URI in the Record-Route
         header field to be a SIP URI.

プロキシがTLSの上に要求を受け取って、非TLS接続の上にそれを出したなら、プロキシは、SIPS URIになるようにRecord-ルートヘッダーフィールドにおけるURIを書き直さなければなりません。 プロキシが非TLS接続の上に要求を受け取って、TLSの上にそれを出したなら、プロキシは、SIP URIになるようにRecord-ルートヘッダーフィールドにおけるURIを書き直さなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 112]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[112ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         The new URI provided by the proxy MUST satisfy the same
         constraints on URIs placed in Record-Route header fields in
         requests (see Step 4 of Section 16.6) with the following
         modifications:

プロキシによって提供された新しいURIは要求(セクション16.6のStep4を見る)におけるRecord-ルートヘッダーフィールドに置かれたURIにおける同じ規制を以下の変更に満たさなければなりません:

         The URI SHOULD NOT contain the transport parameter unless the
         proxy has knowledge that the next upstream (as opposed to
         downstream) element that will be in the path of subsequent
         requests supports that transport.

プロキシにその後の要求の経路にある次の上流(川下と対照的に)の要素がその輸送をサポートするという知識がない場合、URI SHOULD NOTは輸送パラメタを含んでいます。

         When a proxy does decide to modify the Record-Route header
         field in the response, one of the operations it performs is
         locating the Record-Route value that it had inserted.  If the
         request spiraled, and the proxy inserted a Record-Route value
         in each iteration of the spiral, locating the correct value in
         the response (which must be the proper iteration in the reverse
         direction) is tricky.  The rules above recommend that a proxy
         wishing to rewrite Record-Route header field values insert
         sufficiently distinct URIs into the Record-Route header field
         so that the right one may be selected for rewriting.  A
         RECOMMENDED mechanism to achieve this is for the proxy to
         append a unique identifier for the proxy instance to the user
         portion of the URI.

プロキシが、応答におけるRecord-ルートヘッダーフィールドを変更すると決めるとき、それが実行する操作の1つはそれが挿入したRecord-ルート値の場所を見つけています。 要求がらせん形になって、プロキシがRecord-ルート値をらせんの各繰り返しに挿入したなら、応答(反対の方向への適切な繰り返しであるに違いない)における正しい値の場所を見つけるのは扱いにくいです。 上の規則は、Record-ルートヘッダーフィールド値を書き直したがっているプロキシが書き直しのために正しい選択できるようにRecord-ルートヘッダーフィールドに十分異なったURIを挿入することを勧めます。 これを達成するRECOMMENDEDメカニズムはプロキシがプロキシインスタンスのためのユニークな識別子をURIのユーザ部分に追加することです。

         When the response arrives, the proxy modifies the first
         Record-Route whose identifier matches the proxy instance.  The
         modification results in a URI without this piece of data
         appended to the user portion of the URI.  Upon the next
         iteration, the same algorithm (find the topmost Record-Route
         header field value with the parameter) will correctly extract
         the next Record-Route header field value inserted by that
         proxy.

応答が到着するとき、プロキシは識別子がプロキシインスタンスに合っている最初のRecord-ルートを変更します。 変更はURIのユーザ部分に追加されたこのデータなしでURIをもたらします。 次の繰り返しのときに、同じアルゴリズム(パラメタで最上のRecord-ルートがヘッダーフィールド値であることがわかる)は正しくそのプロキシによって挿入された次のRecord-ルートヘッダーフィールド価値を抽出するでしょう。

         Not every response to a request to which a proxy adds a
         Record-Route header field value will contain a Record-Route
         header field.  If the response does contain a Record-Route
         header field, it will contain the value the proxy added.

プロキシがRecord-ルートヘッダーフィールド価値を高める要求へのあらゆる応答がRecord-ルートヘッダーフィールドを含むというわけではないでしょう。 応答がRecord-ルートヘッダーフィールドを含んでいると、それはプロキシが高めた価値を含むでしょう。

      9.  Forward response

9. 前進の応答

         After performing the processing described in steps "Aggregate
         Authorization Header Field Values" through "Record-Route", the
         proxy MAY perform any feature specific manipulations on the
         selected response.  The proxy MUST NOT add to, modify, or
         remove the message body.  Unless otherwise specified, the proxy
         MUST NOT remove any header field values other than the Via
         header field value discussed in Section 16.7 Item 3.  In
         particular, the proxy MUST NOT remove any "received" parameter

「集合認可ヘッダーフィールド値」という「記録的なルート」によるステップで説明された処理を実行した後に、プロキシはどんな特徴の特定の操作も選択された応答に実行するかもしれません。 プロキシが加えてはいけない、メッセージ本体を変更するか、または取り除いてください。 別の方法で指定されない場合、プロキシはセクション16.7 Item3で議論したViaヘッダーフィールド価値以外の少しのヘッダーフィールド値も取り除いてはいけません。 特に、プロキシはどんな「受け取られていている」パラメタも取り除いてはいけません。

Rosenberg, et. al.          Standards Track                   [Page 113]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[113ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         it may have added to the next Via header field value while
         processing the request associated with this response.  The
         proxy MUST pass the response to the server transaction
         associated with the response context.  This will result in the
         response being sent to the location now indicated in the
         topmost Via header field value.  If the server transaction is
         no longer available to handle the transmission, the element
         MUST forward the response statelessly by sending it to the
         server transport.  The server transaction might indicate
         failure to send the response or signal a timeout in its state
         machine.  These errors would be logged for diagnostic purposes
         as appropriate, but the protocol requires no remedial action
         from the proxy.

それはこの応答に関連している要求を処理している間、次のViaヘッダーフィールド価値に加えたかもしれません。 プロキシは応答文脈に関連しているサーバ取引への応答を通過しなければなりません。 これは現在最上のViaヘッダーフィールド価値で示されている位置に送られる応答をもたらすでしょう。 サーバ取引がトランスミッションを扱うためにもう利用可能でないなら、要素は、サーバ輸送にそれを送ることによって、国がなく応答を進めなければなりません。 サーバ取引は州のマシンで応答を送るか、またはタイムアウトに合図しないことを示すかもしれません。 これらの誤りは診断目的で適宜登録されるでしょうが、プロトコルはプロキシから改善措置を全く必要としません。

         The proxy MUST maintain the response context until all of its
         associated transactions have been terminated, even after
         forwarding a final response.

関連取引のすべてが終えられるまで、プロキシは応答文脈を維持しなければなりません、最終的な応答を進めた後にさえ。

      10. Generate CANCELs

10. キャンセルを発生させてください。

         If the forwarded response was a final response, the proxy MUST
         generate a CANCEL request for all pending client transactions
         associated with this response context.  A proxy SHOULD also
         generate a CANCEL request for all pending client transactions
         associated with this response context when it receives a 6xx
         response.  A pending client transaction is one that has
         received a provisional response, but no final response (it is
         in the proceeding state) and has not had an associated CANCEL
         generated for it.  Generating CANCEL requests is described in
         Section 9.1.

進められた応答が最終的な応答であったなら、プロキシはこの応答文脈に関連しているすべての未定のクライアント取引を求めるキャンセル要求を発生させなければなりません。 6xx応答を受けるとき、SHOULDがまたクライアント取引までキャンセル要求を発生させるプロキシはこの応答文脈と交際しました。 未定のクライアント取引は暫定的な応答を受けますが、どんな最終的な応答(それは進行状態にある)も受けていなくて、また関連キャンセルがそれのために発生していないものです。 キャンセル要求を発生させるのはセクション9.1で説明されます。

         The requirement to CANCEL pending client transactions upon
         forwarding a final response does not guarantee that an endpoint
         will not receive multiple 200 (OK) responses to an INVITE.  200
         (OK) responses on more than one branch may be generated before
         the CANCEL requests can be sent and processed.  Further, it is
         reasonable to expect that a future extension may override this
         requirement to issue CANCEL requests.

最終的な応答を進めるときのクライアント取引までキャンセルへの要件は、終点がINVITEへの複数の200(OK)の応答を受けないのを保証しません。 200 キャンセル要求を送って、処理できる前に1つ以上の支店における(OK)応答は発生するかもしれません。 さらに、今後の拡大がキャンセル要求を出すというこの要件に優越するかもしれないと予想するのは妥当です。

16.8 Processing Timer C

16.8 処理タイマC

   If timer C should fire, the proxy MUST either reset the timer with
   any value it chooses, or terminate the client transaction.  If the
   client transaction has received a provisional response, the proxy
   MUST generate a CANCEL request matching that transaction.  If the
   client transaction has not received a provisional response, the proxy
   MUST behave as if the transaction received a 408 (Request Timeout)
   response.

タイマCが撃たれるはずであり、プロキシがそれが選ぶどんな値でもタイマをリセットしなければならないか、またはクライアント取引を終えなければならないなら。 クライアント取引が暫定的な応答を受けたなら、プロキシはその取引に合っているキャンセル要求を発生させなければなりません。 クライアント取引が暫定的な応答を受けていないなら、まるで取引が408(Timeoutを要求する)応答を受けるかのようにプロキシは振る舞わなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 114]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[114ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Allowing the proxy to reset the timer allows the proxy to dynamically
   extend the transaction's lifetime based on current conditions (such
   as utilization) when the timer fires.

プロキシがタイマでダイナミックに広げることができるリセットにプロキシを許容して、取引の寿命は、タイマがいつ撃たれるかを現在の条件(利用などの)に基礎づけました。

16.9 Handling Transport Errors

16.9 取り扱い輸送誤り

   If the transport layer notifies a proxy of an error when it tries to
   forward a request (see Section 18.4), the proxy MUST behave as if the
   forwarded request received a 503 (Service Unavailable) response.

要求を転送しようとするとき(セクション18.4を見てください)、トランスポート層が誤りについてプロキシに通知するなら、まるで転送された要求が503(サービスUnavailable)応答を受けるかのようにプロキシは振る舞わなければなりません。

   If the proxy is notified of an error when forwarding a response, it
   drops the response.  The proxy SHOULD NOT cancel any outstanding
   client transactions associated with this response context due to this
   notification.

応答を進めるとき、プロキシが誤りについて通知されるなら、それは応答を落とします。 プロキシSHOULD NOTはこの通知のためにこの応答文脈に関連しているどんな傑出しているクライアント取引も中止します。

      If a proxy cancels its outstanding client transactions, a single
      malicious or misbehaving client can cause all transactions to fail
      through its Via header field.

プロキシが傑出しているクライアント取引を中止するなら、独身の悪意があるかふらちな事をしているクライアントはViaヘッダーフィールドを通してすべての取引に失敗できます。

16.10 CANCEL Processing

16.10 キャンセル処理

   A stateful proxy MAY generate a CANCEL to any other request it has
   generated at any time (subject to receiving a provisional response to
   that request as described in section 9.1).  A proxy MUST cancel any
   pending client transactions associated with a response context when
   it receives a matching CANCEL request.

statefulプロキシはそれがいつでも発生させたいかなる他の要求(セクション9.1で説明されるようにその要求への暫定的な応答を受けることを条件とした)にもキャンセルを発生させるかもしれません。 合っているキャンセル要求を受け取るとき、プロキシは応答文脈に関連しているどんな未定のクライアント取引も中止しなければなりません。

   A stateful proxy MAY generate CANCEL requests for pending INVITE
   client transactions based on the period specified in the INVITE's
   Expires header field elapsing.  However, this is generally
   unnecessary since the endpoints involved will take care of signaling
   the end of the transaction.

statefulプロキシはINVITEのExpiresヘッダーフィールド経過で指定された期間に基づく未定のINVITEクライアント取引を求めるキャンセル要求を発生させるかもしれません。 しかしながら、かかわった終点が取引の終わりに合図するように注意するので、一般に、これは不要です。

   While a CANCEL request is handled in a stateful proxy by its own
   server transaction, a new response context is not created for it.
   Instead, the proxy layer searches its existing response contexts for
   the server transaction handling the request associated with this
   CANCEL.  If a matching response context is found, the element MUST
   immediately return a 200 (OK) response to the CANCEL request.  In
   this case, the element is acting as a user agent server as defined in
   Section 8.2.  Furthermore, the element MUST generate CANCEL requests
   for all pending client transactions in the context as described in
   Section 16.7 step 10.

キャンセル要求はstatefulプロキシでそれ自身のサーバ取引で扱われますが、新しい応答関係はそれのために作成されません。 代わりに、プロキシ層は要求がこのキャンセルに関連づけたサーバ取引取り扱いのための既存の応答文脈を捜します。 合っている応答文脈が見つけられるなら、要素はすぐに、キャンセル要求への200(OK)応答を返さなければなりません。 この場合、要素はセクション8.2で定義されるユーザエージェントサーバとして作用しています。 その上、要素はセクション16.7ステップ10で説明されるように文脈におけるすべての未定のクライアント取引を求めるキャンセル要求を発生させなければなりません。

   If a response context is not found, the element does not have any
   knowledge of the request to apply the CANCEL to.  It MUST statelessly
   forward the CANCEL request (it may have statelessly forwarded the
   associated request previously).

応答文脈が見つけられないなら、要素には、キャンセルを適用する要求に関する少しの知識もありません。 それは前方にキャンセル要求に国がなくなければなりません(それは以前に、国がなく関連要求を転送したかもしれません)。

Rosenberg, et. al.          Standards Track                   [Page 115]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[115ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

16.11 Stateless Proxy

16.11 国がないプロキシ

   When acting statelessly, a proxy is a simple message forwarder.  Much
   of the processing performed when acting statelessly is the same as
   when behaving statefully.  The differences are detailed here.

国がなく行動するとき、プロキシは純真なメッセージ混載業者です。 国がなく行動するとき実行された処理の多くがstatefullyに振る舞うのにおいていつと同じであるか。 違いはここで詳細です。

   A stateless proxy does not have any notion of a transaction, or of
   the response context used to describe stateful proxy behavior.
   Instead, the stateless proxy takes messages, both requests and
   responses, directly from the transport layer (See section 18).  As a
   result, stateless proxies do not retransmit messages on their own.
   They do, however, forward all retransmissions they receive (they do
   not have the ability to distinguish a retransmission from the
   original message).  Furthermore, when handling a request statelessly,
   an element MUST NOT generate its own 100 (Trying) or any other
   provisional response.

国がないプロキシには、取引、またはstatefulプロキシの振舞いについて説明するのに使用される応答文脈のどんな考えもありません。 代わりに、国がないプロキシは伝言を受け取て、要求と直接輸送からの応答の両方が層にされます(セクション18を見てください)。 その結果、国がないプロキシはそれら自身のに関するメッセージを再送しません。 しかしながら、彼らは受けるすべての「再-トランスミッション」を進めます(彼らには、オリジナルのメッセージと「再-トランスミッション」を区別する能力がありません)。 要求国がなさを扱うとき、その上、要素はそれ自身の100(トライ)かいかなる他の暫定的な応答も発生させてはいけません。

   A stateless proxy MUST validate a request as described in Section
   16.3

国がないプロキシはセクション16.3で説明されるように要求を有効にしなければなりません。

   A stateless proxy MUST follow the request processing steps described
   in Sections 16.4 through 16.5 with the following exception:

国がないプロキシはセクション16.4〜16.5で以下の例外で説明された要求処理方法に従わなければなりません:

      o  A stateless proxy MUST choose one and only one target from the
         target set.  This choice MUST only rely on fields in the
         message and time-invariant properties of the server.  In
         particular, a retransmitted request MUST be forwarded to the
         same destination each time it is processed.  Furthermore,
         CANCEL and non-Routed ACK requests MUST generate the same
         choice as their associated INVITE.

o 国がないプロキシは目標セットから唯一無二の1個の目標を選ばなければなりません。 この選択はサーバのメッセージと時間不変な所有地の分野を当てにするだけでよいです。それが処理されるたびに特に、再送された要求を同じ目的地に転送しなければなりません。 その上、キャンセルと非発送されたACK要求はそれらの関連INVITEと同じ選択を発生させなければなりません。

   A stateless proxy MUST follow the request processing steps described
   in Section 16.6 with the following exceptions:

国がないプロキシはセクション16.6で以下の例外で説明された要求処理方法に従わなければなりません:

      o  The requirement for unique branch IDs across space and time
         applies to stateless proxies as well.  However, a stateless
         proxy cannot simply use a random number generator to compute
         the first component of the branch ID, as described in Section
         16.6 bullet 8.  This is because retransmissions of a request
         need to have the same value, and a stateless proxy cannot tell
         a retransmission from the original request.  Therefore, the
         component of the branch parameter that makes it unique MUST be
         the same each time a retransmitted request is forwarded.  Thus
         for a stateless proxy, the branch parameter MUST be computed as
         a combinatoric function of message parameters which are
         invariant on retransmission.

o スペースと時間の向こう側のユニークなブランチIDのための要件はまた、国がないプロキシに適用されます。 しかしながら、国がないプロキシはブランチIDの最初の成分を計算するのに乱数発生器を絶対に使用できません、セクション16.6弾丸8で説明されるように。 これは同じ値、および国がないプロキシがある要求の必要性の「再-トランスミッション」が「再-トランスミッション」とオリジナルの要求を見分けることができないからです。 したがって、それをユニークにするブランチパラメタの成分は再送された要求を転送する各回に同じであるに違いありません。 したがって、国がないプロキシに関して、「再-トランスミッション」に不変なメッセージパラメタのcombinatoric関数としてブランチパラメタを計算しなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 116]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[116ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         The stateless proxy MAY use any technique it likes to guarantee
         uniqueness of its branch IDs across transactions.  However, the
         following procedure is RECOMMENDED.  The proxy examines the
         branch ID in the topmost Via header field of the received
         request.  If it begins with the magic cookie, the first
         component of the branch ID of the outgoing request is computed
         as a hash of the received branch ID.  Otherwise, the first
         component of the branch ID is computed as a hash of the topmost
         Via, the tag in the To header field, the tag in the From header
         field, the Call-ID header field, the CSeq number (but not
         method), and the Request-URI from the received request.  One of
         these fields will always vary across two different
         transactions.

国がないプロキシは取引の向こう側に保証するそれがブランチIDのユニークさが好きであるどんなテクニックも使用するかもしれません。 しかしながら、以下の手順はRECOMMENDEDです。 プロキシは受信された要求の最上のViaヘッダーフィールドにおけるブランチIDを調べます。 魔法のクッキーで始まるなら、送信する要求のブランチIDの最初の成分は容認されたブランチIDの細切れ肉料理として計算されます。 さもなければ、ブランチIDの最初の成分は最上のViaの細切れ肉料理、Toヘッダーフィールドにおけるタグ、Fromヘッダーフィールドにおけるタグ、Call-IDヘッダーフィールド、CSeq番号(しかし、方法でない)、およびRequest-URIとして受信された要求から計算されます。 これらの分野の1つは2つの異なった取引の向こう側にいつも異なるでしょう。

      o  All other message transformations specified in Section 16.6
         MUST result in the same transformation of a retransmitted
         request.  In particular, if the proxy inserts a Record-Route
         value or pushes URIs into the Route header field, it MUST place
         the same values in retransmissions of the request.  As for the
         Via branch parameter, this implies that the transformations
         MUST be based on time-invariant configuration or
         retransmission-invariant properties of the request.

o セクション16.6で指定された他のすべてのメッセージ変化が再送された要求の同じ変化をもたらさなければなりません。 プロキシがRecord-ルート値を挿入するか、またはRouteヘッダーフィールドにURIを押し込むなら、特に、それは同じ値を要求の「再-トランスミッション」に置かなければなりません。 Viaブランチパラメタに関して、これは、変化を要求の時間不変な構成か「再-トランスミッション」-不変式の特性に基礎づけなければならないのを含意します。

      o  A stateless proxy determines where to forward the request as
         described for stateful proxies in Section 16.6 Item 10.  The
         request is sent directly to the transport layer instead of
         through a client transaction.

o 国がないプロキシは、セクション16.6 Item10のstatefulプロキシのために説明されるように要求をどこに転送するかを決心しています。 クライアント取引の代わりに直接トランスポート層に要求を送ります。

         Since a stateless proxy must forward retransmitted requests to
         the same destination and add identical branch parameters to
         each of them, it can only use information from the message
         itself and time-invariant configuration data for those
         calculations.  If the configuration state is not time-invariant
         (for example, if a routing table is updated) any requests that
         could be affected by the change may not be forwarded
         statelessly during an interval equal to the transaction timeout
         window before or after the change.  The method of processing
         the affected requests in that interval is an implementation
         decision.  A common solution is to forward them transaction
         statefully.

国がないプロキシが再送された要求を同じ目的地に転送して、同じブランチパラメタをそれぞれのそれらに加えなければならないので、それはそれらの計算にメッセージからの情報自体と時間不変なコンフィギュレーション・データを使用できるだけです。 構成状態が時間不変でないなら(例えば経路指定テーブルをアップデートするなら)、変化で影響を受けることができたどんな要求も変化の前または後に取引タイムアウトウィンドウと等しい間隔の間、国がなく転送されないかもしれません。 その間隔で影響を受ける要求を処理する方法は実現決定です。 一般的な解決策はstatefullyに取引をそれらに送ることです。

   Stateless proxies MUST NOT perform special processing for CANCEL
   requests.  They are processed by the above rules as any other
   requests.  In particular, a stateless proxy applies the same Route
   header field processing to CANCEL requests that it applies to any
   other request.

国がないプロキシはキャンセル要求のための特別な処理を実行してはいけません。 それらはいかなる他の要求としても上の規則で処理されます。 特に、国がないプロキシはそれがいかなる他の要求にも適用されるというキャンセル要求に同じRouteヘッダーフィールド処理を適用します。

Rosenberg, et. al.          Standards Track                   [Page 117]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[117ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Response processing as described in Section 16.7 does not apply to a
   proxy behaving statelessly.  When a response arrives at a stateless
   proxy, the proxy MUST inspect the sent-by value in the first
   (topmost) Via header field value.  If that address matches the proxy,
   (it equals a value this proxy has inserted into previous requests)
   the proxy MUST remove that header field value from the response and
   forward the result to the location indicated in the next Via header
   field value.  The proxy MUST NOT add to, modify, or remove the
   message body.  Unless specified otherwise, the proxy MUST NOT remove
   any other header field values.  If the address does not match the
   proxy, the message MUST be silently discarded.

セクション16.7で説明される応答処理は国がなく振る舞うプロキシに適用されません。 応答が国がないプロキシに到着すると、プロキシは、発信しているのをヘッダーフィールドを通した1番目の値(最上の)が評価する点検しなければなりません。 そのアドレスがプロキシに合っているなら、(それはこのプロキシが前の要求に挿入した値と等しいです)プロキシは位置への結果が次のViaヘッダーフィールド価値で示した応答とフォワードからそのヘッダーフィールド値を取り除かなければなりません。 プロキシが加えてはいけない、メッセージ本体を変更するか、または取り除いてください。 別の方法で指定されない場合、プロキシはいかなる他のヘッダーフィールド値も取り除いてはいけません。 アドレスがプロキシに合っていないなら、静かにメッセージを捨てなければなりません。

16.12 Summary of Proxy Route Processing

16.12 プロキシルート処理の概要

   In the absence of local policy to the contrary, the processing a
   proxy performs on a request containing a Route header field can be
   summarized in the following steps.

それと反対なローカルの方針がないとき、以下のステップにプロキシがRouteヘッダーフィールドを含む要求に実行する処理をまとめることができます。

      1.  The proxy will inspect the Request-URI.  If it indicates a
          resource owned by this proxy, the proxy will replace it with
          the results of running a location service.  Otherwise, the
          proxy will not change the Request-URI.

1. プロキシはRequest-URIを点検するでしょう。 このプロキシによって所有されていたリソースを示すと、プロキシはそれを位置のサービスを走らせるという結果に取り替えるでしょう。 さもなければ、プロキシはRequest-URIを変えないでしょう。

      2.  The proxy will inspect the URI in the topmost Route header
          field value.  If it indicates this proxy, the proxy removes it
          from the Route header field (this route node has been
          reached).

2. プロキシは最上のRouteヘッダーフィールド価値におけるURIを点検するでしょう。 このプロキシを示すなら、プロキシはRouteヘッダーフィールドからそれを取り除きます(このルートノードに達しました)。

      3.  The proxy will forward the request to the resource indicated
          by the URI in the topmost Route header field value or in the
          Request-URI if no Route header field is present.  The proxy
          determines the address, port and transport to use when
          forwarding the request by applying the procedures in [4] to
          that URI.

3. プロキシはどんなRouteヘッダーフィールドも存在していないなら最上のRouteヘッダーフィールド価値かRequest-URIにおけるURIによって示されたリソースに要求を転送するでしょう。 [4]でそのURIに手順を適用することによって要求を転送するとき、プロキシは使用へのアドレス、ポート、および輸送を決定します。

   If no strict-routing elements are encountered on the path of the
   request, the Request-URI will always indicate the target of the
   request.

厳しいルーティング要素が全く要求の経路で遭遇しないと、Request-URIはいつも要求の目標を示すでしょう。

16.12.1 Examples

16.12.1 例

16.12.1.1 Basic SIP Trapezoid

16.12.1.1 基本的な一口台形

   This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with
   both proxies record-routing.  Here is the flow.

このシナリオは基本的なSIP台形、両方のプロキシが記録的なルーティングしているU1->P1->P2->U2です。 ここに、流れがあります。

Rosenberg, et. al.          Standards Track                   [Page 118]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[118ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   U1 sends:

U1は発信します:

      INVITE sip:callee@domain.com SIP/2.0
      Contact: sip:caller@u1.example.com

INVITE一口: callee@domain.com SIP/2.0Contact: 一口: caller@u1.example.com

   to P1.  P1 is an outbound proxy.  P1 is not responsible for
   domain.com, so it looks it up in DNS and sends it there.  It also
   adds a Record-Route header field value:

P1に。 P1は外国行きのプロキシです。 P1はdomain.comに責任がないので、それは、DNSでそれを調べて、それをそこに送ります。 また、それはRecord-ルートヘッダーフィールド価値を高めます:

      INVITE sip:callee@domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p1.example.com;lr>

INVITE一口: callee@domain.com SIP/2.0Contact: 一口: caller@u1.example.com Record-ルート: <一口: p1.example.com; lr>。

   P2 gets this.  It is responsible for domain.com so it runs a location
   service and rewrites the Request-URI.  It also adds a Record-Route
   header field value.  There is no Route header field, so it resolves
   the new Request-URI to determine where to send the request:

P2はこれを得ます。 domain.comに責任があって、それは、位置のサービスを走らせるので、Request-URIを書き直します。 また、それはRecord-ルートヘッダーフィールド価値を高めます。 Routeヘッダーフィールドが全くないので、要求をどこに送るかを決定するために新しいRequest-URIを決議します:

      INVITE sip:callee@u2.domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p2.domain.com;lr>
      Record-Route: <sip:p1.example.com;lr>

INVITE一口: callee@u2.domain.com SIP/2.0Contact: 一口: caller@u1.example.com Record-ルート: <一口: p2.domain.com; lrの>の記録的なルート: <一口: p1.example.com; lr>。

   The callee at u2.domain.com gets this and responds with a 200 OK:

u2.domain.comの訪問される人は、200OKでこれを得て、応じます:

      SIP/2.0 200 OK
      Contact: sip:callee@u2.domain.com
      Record-Route: <sip:p2.domain.com;lr>
      Record-Route: <sip:p1.example.com;lr>

一口/2.0 200OK接触: 一口: callee@u2.domain.com Record-ルート: <一口: p2.domain.com; lrの>の記録的なルート: <一口: p1.example.com; lr>。

   The callee at u2 also sets its dialog state's remote target URI to
   sip:caller@u1.example.com and its route set to:

また、u2の訪問される人は、対話状態のリモート目標URIにちびちび飲むように設定します: caller@u1.example.com とそのルートは以下のことのためにセットしました。

      (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

(<一口: p2.domain.com; <一口: lr>、p1.example.com; lr>)

   This is forwarded by P2 to P1 to U1 as normal.  Now, U1 sets its
   dialog state's remote target URI to sip:callee@u2.domain.com and its
   route set to:

これはP2によって正常な同じくらいU1へのP1に送られます。 今、U1は、対話状態のリモート目標URIにちびちび飲むように設定します: callee@u2.domain.com とそのルートは以下のことのためにセットしました。

      (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

(<一口: p1.example.com; <一口: lr>、p2.domain.com; lr>)

   Since all the route set elements contain the lr parameter, U1
   constructs the following BYE request:

すべてのルートセット要素がlrパラメタを含んでいるので、U1は以下のBYE要求を構成します:

      BYE sip:callee@u2.domain.com SIP/2.0
      Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

BYE一口: callee@u2.domain.com SIP/2.0Route: <一口: p1.example.com; <一口: lr>、p2.domain.com; lr>。

Rosenberg, et. al.          Standards Track                   [Page 119]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[119ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   As any other element (including proxies) would do, it resolves the
   URI in the topmost Route header field value using DNS to determine
   where to send the request.  This goes to P1.  P1 notices that it is
   not responsible for the resource indicated in the Request-URI so it
   doesn't change it.  It does see that it is the first value in the
   Route header field, so it removes that value, and forwards the
   request to P2:

(プロキシを含んでいます)がするいかなる他の要素としても、それは、要求をどこに送るかを決定するのにDNSを使用することで最上のRouteヘッダーフィールド価値におけるURIを決議します。 これはP1に行きます。 P1が、それはRequest-URIで示されたリソースに責任がないのに気付くので、それはそれを変えません。 それがRouteヘッダーフィールドにおいて最初の値であることが見られるので、その値を移して、要求をP2に転送します:

      BYE sip:callee@u2.domain.com SIP/2.0
      Route: <sip:p2.domain.com;lr>

BYE一口: callee@u2.domain.com SIP/2.0Route: <一口: p2.domain.com; lr>。

   P2 also notices it is not responsible for the resource indicated by
   the Request-URI (it is responsible for domain.com, not
   u2.domain.com), so it doesn't change it.  It does see itself in the
   first Route header field value, so it removes it and forwards the
   following to u2.domain.com based on a DNS lookup against the
   Request-URI:

また、P2が、それはRequest-URIによって示されたリソースに責任がないのに(それはu2.domain.comではなく、domain.comに責任があります)気付くので、それはそれを変えません。 最初のRouteヘッダーフィールド価値でそれ自体を見るので、それを移して、Request-URIに対するDNSルックアップに基づくu2.domain.comに以下を送ります:

      BYE sip:callee@u2.domain.com SIP/2.0

BYE一口: callee@u2.domain.com SIP/2.0

16.12.1.2 Traversing a Strict-Routing Proxy

16.12.1.2 厳しいルート設定プロキシを横断すること。

   In this scenario, a dialog is established across four proxies, each
   of which adds Record-Route header field values.  The third proxy
   implements the strict-routing procedures specified in RFC 2543 and
   many works in progress.

このシナリオに、対話は4つのプロキシの向こう側に確立されます。それはそれぞれRecord-ルートヘッダーフィールド値を加えます。 第3代プロキシはRFC2543と多くの執筆中の作品で指定された厳しいルーティング手順を実行します。

      U1->P1->P2->P3->P4->U2

U1->、P1、-、>P2->、P3、-、>P4->、U2

   The INVITE arriving at U2 contains:

U2に到着するINVITEは以下を含んでいます。

      INVITE sip:callee@u2.domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p4.domain.com;lr>
      Record-Route: <sip:p3.middle.com>
      Record-Route: <sip:p2.example.com;lr>
      Record-Route: <sip:p1.example.com;lr>

INVITE一口: callee@u2.domain.com SIP/2.0Contact: 一口: caller@u1.example.com Record-ルート: <一口: p4.domain.com; lrの>の記録的なルート: <一口: p3.middle.comの>の記録的なルート: <一口: p2.example.com; lrの>の記録的なルート: <一口: p1.example.com; lr>。

   Which U2 responds to with a 200 OK.  Later, U2 sends the following
   BYE request to P4 based on the first Route header field value.

U2は200OKで応じます。 その後、U2は最初のRouteヘッダーフィールド価値に基づくP4に以下のBYE要求を送ります。

      BYE sip:caller@u1.example.com SIP/2.0
      Route: <sip:p4.domain.com;lr>
      Route: <sip:p3.middle.com>
      Route: <sip:p2.example.com;lr>
      Route: <sip:p1.example.com;lr>

BYE一口: caller@u1.example.com SIP/2.0Route: <一口: p4.domain.com; lr>ルート: <一口: p3.middle.com>ルート: <一口: p2.example.com; lr>ルート: <一口: p1.example.com; lr>。

Rosenberg, et. al.          Standards Track                   [Page 120]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[120ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   P4 is not responsible for the resource indicated in the Request-URI
   so it will leave it alone.  It notices that it is the element in the
   first Route header field value so it removes it.  It then prepares to
   send the request based on the now first Route header field value of
   sip:p3.middle.com, but it notices that this URI does not contain the
   lr parameter, so before sending, it reformats the request to be:

P4はRequest-URIで示されたリソースに責任がないので、それはそれを放っておくでしょう。 それが最初のRouteヘッダーフィールド価値における要素であるのでそれを取り除くのに気付きます。 次に、それは、現在に基づいた一口の最初のRouteヘッダーフィールド価値を要求に送るのを準備します: p3.middle.com、このURIがlrパラメタを含まないのに気付く、発信する前に、そのように、それが再フォーマットである、である:要求

      BYE sip:p3.middle.com SIP/2.0
      Route: <sip:p2.example.com;lr>
      Route: <sip:p1.example.com;lr>
      Route: <sip:caller@u1.example.com>

BYE一口: p3.middle.com SIP/2.0Route: <一口: p2.example.com; lr>ルート: <一口: p1.example.com; lr>ルート: <一口: caller@u1.example.com 、gt。

   P3 is a strict router, so it forwards the following to P2:

P3が厳しいルータであるので、以下をP2に送ります:

      BYE sip:p2.example.com;lr SIP/2.0
      Route: <sip:p1.example.com;lr>
      Route: <sip:caller@u1.example.com>

BYE一口: p2.example.com; lr SIP/2.0Route: <一口: p1.example.com; lr>ルート: <一口: caller@u1.example.com 、gt。

   P2 sees the request-URI is a value it placed into a Record-Route
   header field, so before further processing, it rewrites the request
   to be:

P2が、要求URIがそれがRecord-ルートヘッダーフィールドに置いた値であることがわかるので、さらに処理する前に、それはである:要求を書き直します。

      BYE sip:caller@u1.example.com SIP/2.0
      Route: <sip:p1.example.com;lr>

BYE一口: caller@u1.example.com SIP/2.0Route: <一口: p1.example.com; lr>。

   P2 is not responsible for u1.example.com, so it sends the request to
   P1 based on the resolution of the Route header field value.

P2はu1.example.comに責任がないので、それはRouteヘッダーフィールド価値の解決に基づくP1に要求を送ります。

   P1 notices itself in the topmost Route header field value, so it
   removes it, resulting in:

P1が最上のRouteヘッダーフィールド価値で気付くので、以下となって、それはそれを取り除きます。

      BYE sip:caller@u1.example.com SIP/2.0

BYE一口: caller@u1.example.com SIP/2.0

   Since P1 is not responsible for u1.example.com and there is no Route
   header field, P1 will forward the request to u1.example.com based on
   the Request-URI.

P1はu1.example.comに責任がなくて、またRouteヘッダーフィールドが全くないので、P1はRequest-URIに基づくu1.example.comに要求を転送するでしょう。

16.12.1.3 Rewriting Record-Route Header Field Values

16.12.1.3 記録的なルートヘッダーフィールド値を書き直すこと。

   In this scenario, U1 and U2 are in different private namespaces and
   they enter a dialog through a proxy P1, which acts as a gateway
   between the namespaces.

このシナリオには、異なった個人的な名前空間にU1とU2があります、そして、それらはプロキシP1を通して対話に入ります。P1は名前空間の間のゲートウェイとして機能します。

      U1->P1->U2

U1、-、>P1->、U2

Rosenberg, et. al.          Standards Track                   [Page 121]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[121ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   U1 sends:

U1は発信します:

      INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
      Contact: <sip:caller@u1.leftprivatespace.com>

INVITE一口: callee@gateway.leftprivatespace.com SIP/2.0Contact: <一口: caller@u1.leftprivatespace.com 、gt。

   P1 uses its location service and sends the following to U2:

P1は位置のサービスを利用して、以下をU2に送ります:

      INVITE sip:callee@rightprivatespace.com SIP/2.0
      Contact: <sip:caller@u1.leftprivatespace.com>
      Record-Route: <sip:gateway.rightprivatespace.com;lr>

INVITE一口: callee@rightprivatespace.com SIP/2.0Contact: <一口: caller@u1.leftprivatespace.com 、gt;、記録的なルート: <一口: gateway.rightprivatespace.com; lr>。

   U2 sends this 200 (OK) back to P1:

U2は(OKに)この200をP1に送り返します:

      SIP/2.0 200 OK
      Contact: <sip:callee@u2.rightprivatespace.com>
      Record-Route: <sip:gateway.rightprivatespace.com;lr>

一口/2.0 200OK接触: <一口: callee@u2.rightprivatespace.com 、gt;、記録的なルート: <一口: gateway.rightprivatespace.com; lr>。

   P1 rewrites its Record-Route header parameter to provide a value that
   U1 will find useful, and sends the following to U1:

P1はU1が役に立つのがわかる値を提供するためにRecord-ルートヘッダーパラメタを書き直して、以下をU1に送ります:

      SIP/2.0 200 OK
      Contact: <sip:callee@u2.rightprivatespace.com>
      Record-Route: <sip:gateway.leftprivatespace.com;lr>

一口/2.0 200OK接触: <一口: callee@u2.rightprivatespace.com 、gt;、記録的なルート: <一口: gateway.leftprivatespace.com; lr>。

   Later, U1 sends the following BYE request to P1:

その後、U1は以下のBYE要求をP1に送ります:

      BYE sip:callee@u2.rightprivatespace.com SIP/2.0
      Route: <sip:gateway.leftprivatespace.com;lr>

BYE一口: callee@u2.rightprivatespace.com SIP/2.0Route: <一口: gateway.leftprivatespace.com; lr>。

   which P1 forwards to U2 as:

U2への以下としてのどのP1フォワード

      BYE sip:callee@u2.rightprivatespace.com SIP/2.0

BYE一口: callee@u2.rightprivatespace.com SIP/2.0

17 Transactions

17の取引

   SIP is a transactional protocol: interactions between components take
   place in a series of independent message exchanges.  Specifically, a
   SIP transaction consists of a single request and any responses to
   that request, which include zero or more provisional responses and
   one or more final responses.  In the case of a transaction where the
   request was an INVITE (known as an INVITE transaction), the
   transaction also includes the ACK only if the final response was not
   a 2xx response.  If the response was a 2xx, the ACK is not considered
   part of the transaction.

SIPは取引のプロトコルです: コンポーネントの間の相互作用は一連の独立している交換処理で起こります。 明確に、SIP取引はただ一つの要求とその要求へのどんな応答からも成ります。(応答はゼロか、より暫定的な応答と1つ以上の最終的な応答を含んでいます)。 また、要求がINVITE(INVITE取引として、知られている)であった取引の場合では、取引は最終的な応答が2xx応答でなかった場合にだけACKを含んでいます。 応答が2xxであったなら、ACKは取引の一部であると考えられません。

      The reason for this separation is rooted in the importance of
      delivering all 200 (OK) responses to an INVITE to the UAC.  To
      deliver them all to the UAC, the UAS alone takes responsibility

この分離の理由はINVITEへのすべての200(OK)の応答をUACに渡す重要性に根づきます。 それらを皆、UACに渡すために、UASだけが責任を取ります。

Rosenberg, et. al.          Standards Track                   [Page 122]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[122ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      for retransmitting them (see Section 13.3.1.4), and the UAC alone
      takes responsibility for acknowledging them with ACK (see Section
      13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is
      effectively considered its own transaction.

セクション13.2を見てください。それらを再送する、(セクション13.3.1を見てください、.4)、UACだけがACKと共にそれらを承認することへの責任を取る、(.2 .4)。 このACKが単にUACによって再送されるので、事実上、それはそれ自身の取引であると考えられます。

   Transactions have a client side and a server side.  The client side
   is known as a client transaction and the server side as a server
   transaction.  The client transaction sends the request, and the
   server transaction sends the response.  The client and server
   transactions are logical functions that are embedded in any number of
   elements.  Specifically, they exist within user agents and stateful
   proxy servers.  Consider the example in Section 4.  In this example,
   the UAC executes the client transaction, and its outbound proxy
   executes the server transaction.  The outbound proxy also executes a
   client transaction, which sends the request to a server transaction
   in the inbound proxy.  That proxy also executes a client transaction,
   which in turn sends the request to a server transaction in the UAS.
   This is shown in Figure 4.

取引には、クライアント側とサーバ側があります。 クライアント側はサーバ取引としてのクライアント取引とサーバ側として知られています。 クライアント取引は要求を送ります、そして、サーバ取引は応答を送ります。 クライアントとサーバ取引はいろいろな要素に埋め込まれている論理関数です。 明確に、それらは、ユーザエージェントの中に存在していて、プロキシサーバをstatefulします。 セクション4の例を考えてください。 この例では、UACはクライアント取引を実行します、そして、外国行きのプロキシはサーバ取引を実行します。 また、外国行きのプロキシはクライアント取引を実行します。(それは、本国行きのプロキシでサーバ取引に要求を送ります)。 また、そのプロキシはUASでのサーバ取引への要求が順番に発信するクライアント取引を実行します。 これは図4に示されます。

   +---------+        +---------+        +---------+        +---------+
   |      +-+|Request |+-+   +-+|Request |+-+   +-+|Request |+-+      |
   |      |C||------->||S|   |C||------->||S|   |C||------->||S|      |
   |      |l||        ||e|   |l||        ||e|   |l||        ||e|      |
   |      |i||        ||r|   |i||        ||r|   |i||        ||r|      |
   |      |e||        ||v|   |e||        ||v|   |e||        ||v|      |
   |      |n||        ||e|   |n||        ||e|   |n||        ||e|      |
   |      |t||        ||r|   |t||        ||r|   |t||        ||r|      |
   |      | ||        || |   | ||        || |   | ||        || |      |
   |      |T||        ||T|   |T||        ||T|   |T||        ||T|      |
   |      |r||        ||r|   |r||        ||r|   |r||        ||r|      |
   |      |a||        ||a|   |a||        ||a|   |a||        ||a|      |
   |      |n||        ||n|   |n||        ||n|   |n||        ||n|      |
   |      |s||Response||s|   |s||Response||s|   |s||Response||s|      |
   |      +-+|<-------|+-+   +-+|<-------|+-+   +-+|<-------|+-+      |
   +---------+        +---------+        +---------+        +---------+
      UAC               Outbound           Inbound              UAS
                        Proxy               Proxy

+---------+ +---------+ +---------+ +---------+ | +-+|要求|+-+ +-+|要求|+-+ +-+|要求|+-+ | | |C|、|、-、-、-、-、-、--、>|、|S| |C|、|、-、-、-、-、-、--、>|、|S| |C|、|、-、-、-、-、-、--、>|、|S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||応答||s| |s||応答||s| |s||応答||s| | | +-+| <、-、-、-、-、-、--、|+-+ +-+| <、-、-、-、-、-、--、|+-+ +-+| <、-、-、-、-、-、--、|+-+ | +---------+ +---------+ +---------+ +---------+ UACの外国行きの本国行きのUASプロキシプロキシ

                  Figure 4: Transaction relationships

図4: 取引関係

   A stateless proxy does not contain a client or server transaction.
   The transaction exists between the UA or stateful proxy on one side,
   and the UA or stateful proxy on the other side.  As far as SIP
   transactions are concerned, stateless proxies are effectively
   transparent.  The purpose of the client transaction is to receive a
   request from the element in which the client is embedded (call this
   element the "Transaction User" or TU; it can be a UA or a stateful
   proxy), and reliably deliver the request to a server transaction.

国がないプロキシはクライアントかサーバ取引を含んでいません。 取引は反対側の上の半面の上のUAかstatefulプロキシと、UAかstatefulプロキシの間に存在しています。 SIP取引に関する限り、事実上、国がないプロキシは透明です。 クライアント取引の目的は、クライアントが埋め込まれている要素(この要素を「取引ユーザ」かTUと呼んでください; それは、UAかstatefulプロキシであるかもしれない)から要求を受け取って、サーバ取引に要求を確かに提供することです。

Rosenberg, et. al.          Standards Track                   [Page 123]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[123ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The client transaction is also responsible for receiving responses
   and delivering them to the TU, filtering out any response
   retransmissions or disallowed responses (such as a response to ACK).
   Additionally, in the case of an INVITE request, the client
   transaction is responsible for generating the ACK request for any
   final response accepting a 2xx response.

また、クライアント取引もTUに応答を受けて、それらを渡すのに原因となります、どんな応答「再-トランスミッション」か禁じられた応答(ACKへの応答などの)も無視して。 さらに、INVITE要求の場合では、クライアント取引は2xx応答を受け入れながらどんな最終的な応答を求めるACK要求も発生させるのに原因となります。

   Similarly, the purpose of the server transaction is to receive
   requests from the transport layer and deliver them to the TU.  The
   server transaction filters any request retransmissions from the
   network.  The server transaction accepts responses from the TU and
   delivers them to the transport layer for transmission over the
   network.  In the case of an INVITE transaction, it absorbs the ACK
   request for any final response excepting a 2xx response.

同様に、サーバ取引の目的は、トランスポート層から要求を受け取って、それらをTUに渡すことです。 サーバ取引はネットワークからどんな要求「再-トランスミッション」もフィルターにかけます。 サーバ取引は、ネットワークの上でTUから応答を受け入れて、トランスミッションのためにそれらをトランスポート層に渡します。 INVITE取引の場合では、2xx応答を除いてそれはどんな最終的な応答を求めるACK要求も没頭させます。

   The 2xx response and its ACK receive special treatment.  This
   response is retransmitted only by a UAS, and its ACK generated only
   by the UAC.  This end-to-end treatment is needed so that a caller
   knows the entire set of users that have accepted the call.  Because
   of this special handling, retransmissions of the 2xx response are
   handled by the UA core, not the transaction layer.  Similarly,
   generation of the ACK for the 2xx is handled by the UA core.  Each
   proxy along the path merely forwards each 2xx response to INVITE and
   its corresponding ACK.

2xx応答とそのACKは特別な処理を受けます。 この応答は単にUAS、および単にUACによって発生したそのACKによって再送されます。 終わりから終わりへのこの処理が必要であるので、訪問者は呼び出しを受け入れた全体のセットのユーザを知っています。 この特別な取り扱いのために、2xx応答の「再-トランスミッション」は取引層ではなく、UAコアによって扱われます。 同様に、2xxのためのACKの世代はUAコアによって扱われます。 経路に沿った各プロキシは単にINVITEとその対応するACKへのそれぞれの2xx応答を進めます。

17.1 Client Transaction

17.1 クライアント取引

   The client transaction provides its functionality through the
   maintenance of a state machine.

クライアント取引は州のマシンの維持で機能性を提供します。

   The TU communicates with the client transaction through a simple
   interface.  When the TU wishes to initiate a new transaction, it
   creates a client transaction and passes it the SIP request to send
   and an IP address, port, and transport to which to send it.  The
   client transaction begins execution of its state machine.  Valid
   responses are passed up to the TU from the client transaction.

TUは簡単なインタフェースを通ってクライアント取引で交信します。 TUが新しい取引を開始したがっているとき、それは、クライアント取引を作成して、それを送る発信するというSIP要求、IPアドレス、ポート、および輸送をそれに通り過ぎます。 クライアント取引は州のマシンの実行を始めます。 有効回答はクライアント取引からTUまで通過されます。

   There are two types of client transaction state machines, depending
   on the method of the request passed by the TU.  One handles client
   transactions for INVITE requests.  This type of machine is referred
   to as an INVITE client transaction.  Another type handles client
   transactions for all requests except INVITE and ACK.  This is
   referred to as a non-INVITE client transaction.  There is no client
   transaction for ACK.  If the TU wishes to send an ACK, it passes one
   directly to the transport layer for transmission.

TUによって合格された要求の方法によって、2つのタイプのクライアント取引州のマシンがあります。 1つはINVITE要求のためのクライアント取引を扱います。 このタイプのマシンはINVITEクライアント取引と呼ばれます。 別のタイプはINVITE以外のすべての要求とACKのためにクライアント取引を扱います。 これは非INVITEクライアント取引と呼ばれます。 ACKのためのクライアント取引が全くありません。 TUがACKを送りたいなら、それはトランスミッションのために直接トランスポート層に1つを通過します。

Rosenberg, et. al.          Standards Track                   [Page 124]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[124ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The INVITE transaction is different from those of other methods
   because of its extended duration.  Normally, human input is required
   in order to respond to an INVITE.  The long delays expected for
   sending a response argue for a three-way handshake.  On the other
   hand, requests of other methods are expected to complete rapidly.
   Because of the non-INVITE transaction's reliance on a two-way
   handshake, TUs SHOULD respond immediately to non-INVITE requests.

INVITE取引は拡張持続時間で他の方法のものと異なっています。 通常、人間の入力が、INVITEに応じるのに必要です。 応答を送るために予想された長時間の遅延は3方向ハンドシェイクについて賛成の議論をします。 他方では、他の方法の要求が急速に完成すると予想されます。 両用握手への非INVITE取引の信用のために、TUs SHOULDはすぐ非INVITE要求に応じます。

17.1.1 INVITE Client Transaction

17.1.1 クライアント取引を招待してください。

17.1.1.1 Overview of INVITE Transaction

17.1.1.1 招待取引の概観

   The INVITE transaction consists of a three-way handshake.  The client
   transaction sends an INVITE, the server transaction sends responses,
   and the client transaction sends an ACK.  For unreliable transports
   (such as UDP), the client transaction retransmits requests at an
   interval that starts at T1 seconds and doubles after every
   retransmission.  T1 is an estimate of the round-trip time (RTT), and
   it defaults to 500 ms.  Nearly all of the transaction timers
   described here scale with T1, and changing T1 adjusts their values.
   The request is not retransmitted over reliable transports.  After
   receiving a 1xx response, any retransmissions cease altogether, and
   the client waits for further responses.  The server transaction can
   send additional 1xx responses, which are not transmitted reliably by
   the server transaction.  Eventually, the server transaction decides
   to send a final response.  For unreliable transports, that response
   is retransmitted periodically, and for reliable transports, it is
   sent once.  For each final response that is received at the client
   transaction, the client transaction sends an ACK, the purpose of
   which is to quench retransmissions of the response.

INVITE取引は3方向ハンドシェイクから成ります。 クライアント取引はINVITEを送ります、そして、サーバ取引は応答を送ります、そして、クライアント取引はACKを送ります。 頼り無い輸送(UDPなどの)のために、T1秒に始まって、あらゆる「再-トランスミッション」の後に倍増する間隔を置いて、クライアント取引は要求を再送します。 T1は往復の現代(RTT)の見積りです、そして、それは500原稿Nearlyをデフォルトとします。ここで説明された取引タイマのすべてがT1と共に比例します、そして、T1を変えると、それらの値は調整されます。 要求は信頼できる輸送の上に再送されません。 1xx応答を受けた後に、どんな「再-トランスミッション」も全体でやみます、そして、クライアントはさらなる応答を待ちます。 サーバ取引は追加1xx応答を送ることができます。(応答はサーバ取引で確かに伝えられません)。 結局、サーバ取引は、最終的な応答を送ると決めます。 頼り無い輸送において、その応答を定期的に再送します、そして、信頼できる輸送において、それを一度送ります。 クライアント取引のときに受けられるそれぞれの最終的な応答のために、クライアント取引は応答の「再-トランスミッション」を冷却するそれの目的がことであるACKを送ります。

17.1.1.2 Formal Description

17.1.1.2 形式的記述

   The state machine for the INVITE client transaction is shown in
   Figure 5.  The initial state, "calling", MUST be entered when the TU
   initiates a new client transaction with an INVITE request.  The
   client transaction MUST pass the request to the transport layer for
   transmission (see Section 18).  If an unreliable transport is being
   used, the client transaction MUST start timer A with a value of T1.
   If a reliable transport is being used, the client transaction SHOULD
   NOT start timer A (Timer A controls request retransmissions).  For
   any transport, the client transaction MUST start timer B with a value
   of 64*T1 seconds (Timer B controls transaction timeouts).

INVITEクライアント取引のための州のマシンは図5で見せられます。 TUがINVITE要求で新しいクライアント取引を開始するとき、「呼んでいる」初期状態に入らなければなりません。 クライアント取引はトランスミッションのために要求にトランスポート層に合格しなければなりません(セクション18を見てください)。 頼り無い輸送が使用されているなら、クライアント取引はT1の値からタイマAを始動しなければなりません。 信頼できる輸送が使用されているなら、クライアント取引SHOULD NOTはタイマAを始動します(タイマA制御装置は「再-トランスミッション」を要求します)。 どんな輸送のためにも、クライアント取引は64*T1秒(タイマBコントロール取引タイムアウト)の値からタイマBを始動しなければなりません。

   When timer A fires, the client transaction MUST retransmit the
   request by passing it to the transport layer, and MUST reset the
   timer with a value of 2*T1.  The formal definition of retransmit

タイマAが撃たれると、クライアント取引は、それをトランスポート層に通過することによって要求を再送しなければならなくて、2*T1の値でタイマをリセットしなければなりません。 公式の定義、再送

Rosenberg, et. al.          Standards Track                   [Page 125]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[125ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   within the context of the transaction layer is to take the message
   previously sent to the transport layer and pass it to the transport
   layer once more.

中では、取引層の文脈は、以前にトランスポート層に送られた伝言を受け取て、もう一度それをトランスポート層に通過することです。

   When timer A fires 2*T1 seconds later, the request MUST be
   retransmitted again (assuming the client transaction is still in this
   state).  This process MUST continue so that the request is
   retransmitted with intervals that double after each transmission.
   These retransmissions SHOULD only be done while the client
   transaction is in the "calling" state.

タイマAが2*T1秒後に撃たれるとき、再び要求を再送しなければなりません(クライアント取引を仮定するのがまだこの状態にあります)。 この過程が持続しなければならないので、間隔がそんなに二重な状態で要求は各トランスミッションの後に再送されます。 これらのretransmissions SHOULD、クライアント取引が「呼ぶ」状態にある間、単にしてください。

   The default value for T1 is 500 ms.  T1 is an estimate of the RTT
   between the client and server transactions.  Elements MAY (though it
   is NOT RECOMMENDED) use smaller values of T1 within closed, private
   networks that do not permit general Internet connection.  T1 MAY be
   chosen larger, and this is RECOMMENDED if it is known in advance
   (such as on high latency access links) that the RTT is larger.
   Whatever the value of T1, the exponential backoffs on retransmissions
   described in this section MUST be used.

T1が500原稿T1であるので、デフォルト値はクライアントとサーバ取引の間のRTTの見積りです。 要素5月(それはNOT RECOMMENDEDですが)は一般的なインターネット接続を可能にしない閉じていて、私設のネットワークの中でT1の、より小さい値を使用します。 T1 MAY、 より大きい状態で選ばれてください。そうすれば、あらかじめ(高い潜在アクセスリンクでそのような)RTTが、より大きいのが知られているなら、これはRECOMMENDEDです。 T1の値が何であっても、このセクションで説明された「再-トランスミッション」の上の指数のbackoffsを使用しなければなりません。

   If the client transaction is still in the "Calling" state when timer
   B fires, the client transaction SHOULD inform the TU that a timeout
   has occurred.  The client transaction MUST NOT generate an ACK.  The
   value of 64*T1 is equal to the amount of time required to send seven
   requests in the case of an unreliable transport.

タイマBが撃たれるとき、クライアント取引がまだ「呼ぶ」状態にあるなら、クライアント取引SHOULDは、タイムアウトが起こったことをTUに知らせます。 クライアント取引はACKを発生させてはいけません。 64*T1の値は頼り無い輸送の場合で7つの要求を送るのに必要である時間と等しいです。

   If the client transaction receives a provisional response while in
   the "Calling" state, it transitions to the "Proceeding" state. In the
   "Proceeding" state, the client transaction SHOULD NOT retransmit the
   request any longer. Furthermore, the provisional response MUST be
   passed to the TU.  Any further provisional responses MUST be passed
   up to the TU while in the "Proceeding" state.

「呼ぶ」状態では、「進行」状態に移行しますが、クライアント取引が暫定的な応答を受けるなら。 「進行」状態では、クライアント取引SHOULD NOTはもう要求を再送します。 その上、暫定的な応答をTUに通過しなければなりません。 これ以上、「進行」状態にある間、暫定的な応答をTUまで通過しなければなりません。

   When in either the "Calling" or "Proceeding" states, reception of a
   response with status code from 300-699 MUST cause the client
   transaction to transition to "Completed".  The client transaction
   MUST pass the received response up to the TU, and the client
   transaction MUST generate an ACK request, even if the transport is
   reliable (guidelines for constructing the ACK from the response are
   given in Section 17.1.1.3) and then pass the ACK to the transport
   layer for transmission.  The ACK MUST be sent to the same address,
   port, and transport to which the original request was sent.  The
   client transaction SHOULD start timer D when it enters the
   "Completed" state, with a value of at least 32 seconds for unreliable
   transports, and a value of zero seconds for reliable transports.
   Timer D reflects the amount of time that the server transaction can
   remain in the "Completed" state when unreliable transports are used.
   This is equal to Timer H in the INVITE server transaction, whose

300-699からのステータスコードによる応答のレセプションが「呼ぶ」か「進行」州のどちらかで「完成されたこと」への変遷にクライアント取引を引き起こさなければならないと。 クライアント取引が容認された応答をTUまで通過しなければならなくて、クライアント取引は、輸送が信頼できても(応答からACKを組み立てるためのガイドラインは当然のことコネセクション17.1.1の.3です)ACK要求を発生させて、次に、トランスミッションのためにACKをトランスポート層に渡さなければなりません。 ACK MUST、オリジナルの要求が送られた同じアドレス、ポート、および輸送に送ってください。 「完成した」状態に入るとき、クライアント取引SHOULDはタイマDを始動します、頼り無い輸送のための少なくとも32秒の値、および信頼できる輸送のための秒がない値で。 タイマDは頼り無い輸送が使用されているとき、サーバ取引が「完成した」州に残ることができる時間に反射します。 これがINVITEサーバ取引におけるTimer Hと等しい、だれのもの

Rosenberg, et. al.          Standards Track                   [Page 126]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[126ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   default is 64*T1.  However, the client transaction does not know the
   value of T1 in use by the server transaction, so an absolute minimum
   of 32s is used instead of basing Timer D on T1.

デフォルトは64*T1です。 しかしながら、クライアント取引がサーバ取引によって使用中のT1の値を知らないので、Timer DをT1に基礎づけることの代わりに32年代の絶対最小値は使用されます。

   Any retransmissions of the final response that are received while in
   the "Completed" state MUST cause the ACK to be re-passed to the
   transport layer for retransmission, but the newly received response
   MUST NOT be passed up to the TU.  A retransmission of the response is
   defined as any response which would match the same client transaction
   based on the rules of Section 17.1.3.

最終的な応答のどんな「完成した」状態にある間に受け取られていている「再-トランスミッション」も「再-トランスミッション」のためにACKをトランスポート層に再渡させなければなりませんが、新たに受け取られた応答をTUまで通過してはいけません。 応答の「再-トランスミッション」は同じであるセクション17.1.3の規則に基づくクライアント取引のに合っているどんな応答とも定義されます。

Rosenberg, et. al.          Standards Track                   [Page 127]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[127ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

                               |INVITE from TU
             Timer A fires     |INVITE sent
             Reset A,          V                      Timer B fires
             INVITE sent +-----------+                or Transport Err.
               +---------|           |---------------+inform TU
               |         |  Calling  |               |
               +-------->|           |-------------->|
                         +-----------+ 2xx           |
                            |  |       2xx to TU     |
                            |  |1xx                  |
    300-699 +---------------+  |1xx to TU            |
   ACK sent |                  |                     |
resp. to TU |  1xx             V                     |
            |  1xx to TU  -----------+               |
            |  +---------|           |               |
            |  |         |Proceeding |-------------->|
            |  +-------->|           | 2xx           |
            |            +-----------+ 2xx to TU     |
            |       300-699    |                     |
            |       ACK sent,  |                     |
            |       resp. to TU|                     |
            |                  |                     |      NOTE:
            |  300-699         V                     |
            |  ACK sent  +-----------+Transport Err. |  transitions
            |  +---------|           |Inform TU      |  labeled with
            |  |         | Completed |-------------->|  the event
            |  +-------->|           |               |  over the action
            |            +-----------+               |  to take
            |              ^   |                     |
            |              |   | Timer D fires       |
            +--------------+   | -                   |
                               |                     |
                               V                     |
                         +-----------+               |
                         |           |               |
                         | Terminated|<--------------+
                         |           |
                         +-----------+

| TU Timer A炎からのINVITE|INVITEはINVITEが+を送ったB炎をReset A、V Timerに送りました。-----------+か輸送が間違えます。 +---------| |---------------+はTUに知らせます。| | 呼びます。| | +-------->| |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| +-----------+ 2xx| | | TUへの2xx| | |1xx| 300-699 +---------------+ |TUへの1xx| ACKは発信しました。| | | resp TUに| 1xx V| | TUへの1xx-----------+ | | +---------| | | | | |進行|、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +-------->|、| 2xx| | +-----------+ TUへの2xx| | 300-699 | | | ACKは発信しました。| | | resp TUに| | | | | 以下に注意してください。 | 300-699 V| | ACKは+を送りました。-----------+ 輸送は間違えます。 | 変遷| +---------| |TUに知らせてください。| ラベルされます。| | | 完成されます。|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 出来事| +-------->|、|、| 動作の上で| +-----------+ | 取るために| ^ | | | | | タイマD炎| +--------------+ | - | | | V| +-----------+ | | | | | 終わります。| <、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | +-----------+

                 Figure 5: INVITE client transaction

図5: INVITEクライアント取引

   If timer D fires while the client transaction is in the "Completed"
   state, the client transaction MUST move to the terminated state.

クライアント取引が「完成した」状態にある間、タイマDが撃たれるなら、クライアント取引は終えられた状態に動かなければなりません。

   When in either the "Calling" or "Proceeding" states, reception of a
   2xx response MUST cause the client transaction to enter the
   "Terminated" state, and the response MUST be passed up to the TU.
   The handling of this response depends on whether the TU is a proxy

「呼ぶ」か「進行」州のどちらかでは、クライアント取引が2xx応答のレセプションで「終えられた」状態に入らなければならなくて、応答をTUまで通過しなければならないとき。 この応答の取り扱いはTUがプロキシであるかどうかに頼っています。

Rosenberg, et. al.          Standards Track                   [Page 128]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[128ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   core or a UAC core.  A UAC core will handle generation of the ACK for
   this response, while a proxy core will always forward the 200 (OK)
   upstream.  The differing treatment of 200 (OK) between proxy and UAC
   is the reason that handling of it does not take place in the
   transaction layer.

コアかUACコア。 UACコアはこの応答のためにACKの世代を扱うでしょう、プロキシコアがいつも上流へ、200(OK)を進めるでしょうが。 プロキシとUACの間の200(OK)の異なった処理はそれの取り扱いが取引層の中で行われない理由です。

   The client transaction MUST be destroyed the instant it enters the
   "Terminated" state.  This is actually necessary to guarantee correct
   operation.  The reason is that 2xx responses to an INVITE are treated
   differently; each one is forwarded by proxies, and the ACK handling
   in a UAC is different.  Thus, each 2xx needs to be passed to a proxy
   core (so that it can be forwarded) and to a UAC core (so it can be
   acknowledged).  No transaction layer processing takes place.
   Whenever a response is received by the transport, if the transport
   layer finds no matching client transaction (using the rules of
   Section 17.1.3), the response is passed directly to the core.  Since
   the matching client transaction is destroyed by the first 2xx,
   subsequent 2xx will find no match and therefore be passed to the
   core.

「終えられた」状態に入るとすぐに、クライアント取引を破壊しなければなりません。 これが、正しい操作を保証するのに実際に必要です。 理由はINVITEへの2xx応答が異なって扱われるということです。 各々はプロキシによって進められます、そして、UACのACK取り扱いは異なっています。 したがって、各2xxは、プロキシコア(それを進めることができるように)と、そして、UACコアに通過される必要があります(したがって、それを承認できます)。 いいえ取引層の処理は行われます。 クライアント取引に合っていないトランスポート層掘り出し物であるなら輸送で応答を受けるときはいつも(セクション17.1.3の規則を使用して)、応答は直接コアに通過されます。 合っているクライアント取引が最初の2xxによって破壊されるので、その後の2xxはマッチを全く見つけないで、したがって、コアに渡されるでしょう。

17.1.1.3 Construction of the ACK Request

17.1.1.3 ACK要求の工事

   This section specifies the construction of ACK requests sent within
   the client transaction.  A UAC core that generates an ACK for 2xx
   MUST instead follow the rules described in Section 13.

このセクションはクライアント取引の中で送られたACK要求の工事を指定します。 2xxのためにACKを発生させるUACコアは代わりにセクション13で説明された規則に従わなければなりません。

   The ACK request constructed by the client transaction MUST contain
   values for the Call-ID, From, and Request-URI that are equal to the
   values of those header fields in the request passed to the transport
   by the client transaction (call this the "original request").  The To
   header field in the ACK MUST equal the To header field in the
   response being acknowledged, and therefore will usually differ from
   the To header field in the original request by the addition of the
   tag parameter.  The ACK MUST contain a single Via header field, and
   this MUST be equal to the top Via header field of the original
   request.  The CSeq header field in the ACK MUST contain the same
   value for the sequence number as was present in the original request,
   but the method parameter MUST be equal to "ACK".

クライアント取引で構成されたACK要求はクライアント取引で輸送に合格された要求における、それらのヘッダーフィールドの値と等しいCall-ID、From、およびRequest-URIのための値を含まなければなりません(「オリジナルの要求」にこれに電話をしてください)。 ACK MUSTのToヘッダーフィールドは、承認されていて、応答においてToヘッダーフィールドと等しく、したがって、通常、オリジナルの要求でタグパラメタの添加でToヘッダーフィールドと異なるでしょう。 ACK MUSTはただ一つのViaヘッダーフィールドを含んでいます、そして、これはオリジナルの要求のトップViaヘッダーフィールドと等しいに違いありません。 ACKのCSeqヘッダーフィールドはプレゼントのようにオリジナルの要求に一連番号のための同じ値を含まなければなりませんが、方法パラメタは"ACK"と等しいに違いありません。

Rosenberg, et. al.          Standards Track                   [Page 129]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[129ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   If the INVITE request whose response is being acknowledged had Route
   header fields, those header fields MUST appear in the ACK.  This is
   to ensure that the ACK can be routed properly through any downstream
   stateless proxies.

INVITEが、だれの応答が承諾されるかにRouteヘッダーフィールドがあったよう要求するなら、それらのヘッダーフィールドはACKに現れなければなりません。 これは、どんな川下の国がないプロキシを通しても適切にACKを発送できるのを保証するためのものです。

   Although any request MAY contain a body, a body in an ACK is special
   since the request cannot be rejected if the body is not understood.
   Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,
   but if done, the body types are restricted to any that appeared in
   the INVITE, assuming that the response to the INVITE was not 415.  If
   it was, the body in the ACK MAY be any type listed in the Accept
   header field in the 415.

どんな要求もボディーを含むかもしれませんが、ACKのボディーは、ボディーが理解されていないなら要求を拒絶できないので、特別です。 したがって、非2xxのためのACKのボディーのプレースメントはNOT RECOMMENDEDですが、するなら、ボディータイプをINVITEに現れたいずれにも制限します、INVITEへの応答が415でなかったと仮定して。 ACK MAYのボディーはそれがそうであったなら、いくらかそうでした。タイプは415におけるAcceptヘッダーフィールドで記載しました。

   For example, consider the following request:

例えば、以下の要求を考えてください:

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=88sja8x
   Max-Forwards: 70
   Call-ID: 987asjd97y7atg
   CSeq: 986759 INVITE

INVITE一口: bob@biloxi.com SIP/2.0Via: 一口/2.0/UDP pc33.atlanta.com; ブランチ=z9hG4bKkjshdyff To: ボブ<一口: bob@biloxi.com 、gt;、From: アリス<一口: alice@atlanta.com 、gt;、; =88sja8xマックス-フォワードにタグ付けをしてください: 70呼び出しID: 987asjd97y7atg CSeq: 986759 招待

   The ACK request for a non-2xx final response to this request would
   look like this:

ACKは、非2xxのためにこの要求への最終的な応答がこれに似ているよう要求します:

   ACK sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
   To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
   From: Alice <sip:alice@atlanta.com>;tag=88sja8x
   Max-Forwards: 70
   Call-ID: 987asjd97y7atg
   CSeq: 986759 ACK

ACK一口: bob@biloxi.com SIP/2.0Via: 一口/2.0/UDP pc33.atlanta.com; ブランチ=z9hG4bKkjshdyff To: ボブ<一口: bob@biloxi.com 、gt;、;=99sa0xk From:にタグ付けをしてください アリス<一口: alice@atlanta.com 、gt;、; =88sja8xマックス-フォワードにタグ付けをしてください: 70呼び出しID: 987asjd97y7atg CSeq: 986759 ACK

17.1.2 Non-INVITE Client Transaction

17.1.2 非招待クライアント取引

17.1.2.1 Overview of the non-INVITE Transaction

17.1.2.1 非招待取引の概観

   Non-INVITE transactions do not make use of ACK.  They are simple
   request-response interactions.  For unreliable transports, requests
   are retransmitted at an interval which starts at T1 and doubles until
   it hits T2.  If a provisional response is received, retransmissions
   continue for unreliable transports, but at an interval of T2.  The
   server transaction retransmits the last response it sent, which can
   be a provisional or final response, only when a retransmission of the
   request is received.  This is why request retransmissions need to
   continue even after a provisional response; they are to ensure
   reliable delivery of the final response.

非INVITE取引はACKを利用しません。 それらは簡単な要求応答相互作用です。 頼り無い輸送において、T1で始まって、T2を打つまで倍増する間隔を置いて、要求は再送されます。 暫定的な応答が受け取られているなら、「再-トランスミッション」は、頼り無い輸送のために続きますが、T2の間隔で、続きます。 サーバ取引はそれが送った最後の応答を再送します、要求の「再-トランスミッション」が受け取られているときだけ。(応答は暫定的であるか最終的な応答であるかもしれません)。 これは要求「再-トランスミッション」が暫定的な応答の後にさえ続く必要がある理由です。 彼らは最終的な応答の信頼できる配信を確実にすることになっています。

Rosenberg, et. al.          Standards Track                   [Page 130]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[130ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Unlike an INVITE transaction, a non-INVITE transaction has no special
   handling for the 2xx response.  The result is that only a single 2xx
   response to a non-INVITE is ever delivered to a UAC.

INVITE取引と異なって、非INVITE取引には、2xx応答のためのどんな特別な取り扱いもありません。 結果は今までに非INVITEへのただ一つの2xx応答だけをUACに渡すということです。

17.1.2.2 Formal Description

17.1.2.2 形式的記述

   The state machine for the non-INVITE client transaction is shown in
   Figure 6.  It is very similar to the state machine for INVITE.

非INVITEクライアント取引のための州のマシンは図6で見せられます。 INVITEに、それは州のマシンと非常に同様です。

   The "Trying" state is entered when the TU initiates a new client
   transaction with a request.  When entering this state, the client
   transaction SHOULD set timer F to fire in 64*T1 seconds.  The request
   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2).  This
   process continues so that retransmissions occur with an exponentially
   increasing interval that caps at T2.  The default value of T2 is 4s,
   and it represents the amount of time a non-INVITE server transaction
   will take to respond to a request, if it does not respond
   immediately.  For the default values of T1 and T2, this results in
   intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.

TUが要求で新しいクライアント取引を開始するとき、「試みている」状態は入られます。 この状態に入るとき、クライアント取引SHOULDは、タイマFに64*T1秒に発火するように設定します。 トランスミッションのために要求にトランスポート層に合格しなければなりません。 頼り無い輸送が使用中であるなら、クライアント取引は、タイマEにT1秒に発火するように設定しなければなりません。 タイマがまだこの状態では、リセットですが、MINの値がある今回が(2*T1、T2)ですが、タイマEに撃たれるなら。 タイマが再び撃たれるとき、それはMIN(4*T1、T2)にリセットされます。 この過程が持続するので、「再-トランスミッション」はそれがT2でふたをする指数関数的に増加する間隔で現れます。 T2のデフォルト値は4です、そして、非INVITEサーバ取引が要求に応じるにはかかる時間を表します、すぐに応じないなら。 T1とT2のデフォルト値のために、これは500msの間隔、1秒間、2秒間、4秒間、4秒間、4秒間などをもたらします。

   If Timer F fires while the client transaction is still in the
   "Trying" state, the client transaction SHOULD inform the TU about the
   timeout, and then it SHOULD enter the "Terminated" state.  If a
   provisional response is received while in the "Trying" state, the
   response MUST be passed to the TU, and then the client transaction
   SHOULD move to the "Proceeding" state.  If a final response (status
   codes 200-699) is received while in the "Trying" state, the response
   MUST be passed to the TU, and the client transaction MUST transition
   to the "Completed" state.

クライアント取引がまだ発火しますが、Timer Fが発火するなら、「試みている」状態、SHOULDがタイムアウトに関してTUに知らせるクライアント取引、および次に、それでは、SHOULDは「終えられた」状態に入ります。 「試みている」状態では、応答をTUに通過しなければならなくて、次に、クライアント取引SHOULDが「進行」状態に動きますが、暫定的な応答が受け取られているなら。 最終的な応答(ステータスコード200-699)が「試みている」状態にある間、受け取られているなら、応答をTUに通過しなければなりません、そして、クライアント取引は「完成した」状態への変遷を通過しなければなりません。

   If Timer E fires while in the "Proceeding" state, the request MUST be
   passed to the transport layer for retransmission, and Timer E MUST be
   reset with a value of T2 seconds.  If timer F fires while in the
   "Proceeding" state, the TU MUST be informed of a timeout, and the
   client transaction MUST transition to the terminated state.  If a
   final response (status codes 200-699) is received while in the
   "Proceeding" state, the response MUST be passed to the TU, and the
   client transaction MUST transition to the "Completed" state.

Timer Eが「再-トランスミッション」のために「進行」状態で要求にトランスポート層に合格しなければならない間、発火するか、そして、Timer EはT2秒の値があるリセットであるに違いありません。 タイマFが「進行」状態にある間、撃たれるなら、トゥはタイムアウトにおいて知識があるに違いありません、そして、クライアント取引は終えられた状態への変遷を知識がなければなりません。 最終的な応答(ステータスコード200-699)が「進行」状態にある間、受け取られているなら、応答をTUに通過しなければなりません、そして、クライアント取引は「完成した」状態への変遷を通過しなければなりません。

   Once the client transaction enters the "Completed" state, it MUST set
   Timer K to fire in T4 seconds for unreliable transports, and zero
   seconds for reliable transports.  The "Completed" state exists to
   buffer any additional response retransmissions that may be received
   (which is why the client transaction remains there only for

クライアント取引がいったん「完成した」状態に入ると、それは、Timer KにT4秒に信頼できる輸送のために頼り無い輸送にもかかわらず、どんな秒間も、発火しないように設定しなければなりません。 「完成した」状態が受け取られるかもしれないどんな追加応答「再-トランスミッション」もバッファリングするように存在している、(クライアント取引がそこに残っている理由はどれのためのだけものであるか。

Rosenberg, et. al.          Standards Track                   [Page 131]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[131ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   unreliable transports).  T4 represents the amount of time the network
   will take to clear messages between client and server transactions.
   The default value of T4 is 5s.  A response is a retransmission when
   it matches the same transaction, using the rules specified in Section
   17.1.3.  If Timer K fires while in this state, the client transaction
   MUST transition to the "Terminated" state.

頼り無い輸送) T4はネットワークがクライアントとサーバ取引の間の明確なメッセージに始める時間を表します。 T4のデフォルト値は5です。 同じ取引に合っているとき、セクション17.1.3で指定された規則を使用して、応答は「再-トランスミッション」です。 Timer Kがこの状態にある間、発火するなら、クライアント取引は「終えられた」状態への変遷が発火しなければなりません。

   Once the transaction is in the terminated state, it MUST be destroyed
   immediately.

取引が終えられた状態にいったんあると、すぐに、それを破壊しなければなりません。

17.1.3 Matching Responses to Client Transactions

17.1.3 クライアント取引への合っている応答

   When the transport layer in the client receives a response, it has to
   determine which client transaction will handle the response, so that
   the processing of Sections 17.1.1 and 17.1.2 can take place.  The
   branch parameter in the top Via header field is used for this
   purpose.  A response matches a client transaction under two
   conditions:

クライアントのトランスポート層が応答を受けるとき、セクション17.1.1と.2が取ることができる17.1の処理が入賞するのがしたがって、どのクライアント取引が応答を扱うかを決定しなければなりません。 トップViaヘッダーフィールドにおけるブランチパラメタはこのために使用されます。 応答は2つの条件のもとでクライアント取引に合っています:

      1.  If the response has the same value of the branch parameter in
          the top Via header field as the branch parameter in the top
          Via header field of the request that created the transaction.

1. 応答に要求のトップViaヘッダーフィールドにおけるブランチパラメタとしてのトップViaヘッダーフィールドにおける、ブランチパラメタの同じ値があるなら、それは取引を作成しました。

      2.  If the method parameter in the CSeq header field matches the
          method of the request that created the transaction.  The
          method is needed since a CANCEL request constitutes a
          different transaction, but shares the same value of the branch
          parameter.

2. CSeqヘッダーフィールドにおける方法パラメタが要求の方法に合っているなら、それは取引を作成しました。 方法は、キャンセル要求が異なった取引を構成するので必要ですが、ブランチパラメタの同じ値を共有します。

   If a request is sent via multicast, it is possible that it will
   generate multiple responses from different servers.  These responses
   will all have the same branch parameter in the topmost Via, but vary
   in the To tag.  The first response received, based on the rules
   above, will be used, and others will be viewed as retransmissions.
   That is not an error; multicast SIP provides only a rudimentary
   "single-hop-discovery-like" service that is limited to processing a
   single response.  See Section 18.1.1 for details.

マルチキャストで要求を送るなら、異なったサーバから複数の応答を発生させるのは、可能です。 これらの応答はすべて、最上のViaに同じブランチパラメタを持つでしょうが、Toタグで異なってください。 規則に基づいて上で受けられた最初の応答は使用されるでしょう、そして、他のものは「再-トランスミッション」として見なされるでしょう。 それは誤りではありません。 マルチキャストSIPは処理に制限される初歩的な「ただ一つのホップ発見のような」サービスだけにただ一つの応答を提供します。 詳細に関してセクション18.1.1を見てください。

Rosenberg, et. al.          Standards Track                   [Page 132]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[132ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

17.1.4 Handling Transport Errors

17.1.4 取り扱い輸送誤り

                                   |Request from TU
                                   |send request
               Timer E             V
               send request  +-----------+
                   +---------|           |-------------------+
                   |         |  Trying   |  Timer F          |
                   +-------->|           |  or Transport Err.|
                             +-----------+  inform TU        |
                200-699         |  |                         |
                resp. to TU     |  |1xx                      |
                +---------------+  |resp. to TU              |
                |                  |                         |
                |   Timer E        V       Timer F           |
                |   send req +-----------+ or Transport Err. |
                |  +---------|           | inform TU         |
                |  |         |Proceeding |------------------>|
                |  +-------->|           |-----+             |
                |            +-----------+     |1xx          |
                |              |      ^        |resp to TU   |
                | 200-699      |      +--------+             |
                | resp. to TU  |                             |
                |              |                             |
                |              V                             |
                |            +-----------+                   |
                |            |           |                   |
                |            | Completed |                   |
                |            |           |                   |
                |            +-----------+                   |
                |              ^   |                         |
                |              |   | Timer K                 |
                +--------------+   | -                       |
                                   |                         |
                                   V                         |
             NOTE:           +-----------+                   |
                             |           |                   |
         transitions         | Terminated|<------------------+
         labeled with        |           |
         the event           +-----------+
         over the action
         to take

| TUからの要求|Vが要求+を送る要求Timer Eを送ってください。-----------+ +---------| |-------------------+ | | 試みます。| タイマF| +-------->|、| または、輸送が間違える、| +-----------+はTUに知らせます。| 200-699 | | | resp TUに| |1xx| +---------------+ |resp TUに| | | | | タイマE VタイマF| | req+を送ってください。-----------+か輸送が間違えます。 | | +---------| | TUに知らせてください。| | | |進行|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +-------->| |-----+ | | +-----------+ |1xx| | | ^ |TUへのresp| | 200-699 | +--------+ | | resp TUに| | | | | | V| | +-----------+ | | | | | | | 完成されます。| | | | | | | +-----------+ | | ^ | | | | | タイマK| +--------------+ | - | | | V| 以下に注意してください。 +-----------+ | | | | 変遷| 終わります。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+、ラベルされます。| | 出来事+-----------+ 取る行動の上で

                 Figure 6: non-INVITE client transaction

図6: 非INVITEクライアント取引

   When the client transaction sends a request to the transport layer to
   be sent, the following procedures are followed if the transport layer
   indicates a failure.

クライアント取引が送られるトランスポート層に要求を送ると、トランスポート層が失敗を示すなら、以下の手順は従われています。

Rosenberg, et. al.          Standards Track                   [Page 133]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[133ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The client transaction SHOULD inform the TU that a transport failure
   has occurred, and the client transaction SHOULD transition directly
   to the "Terminated" state.  The TU will handle the failover
   mechanisms described in [4].

クライアントトランザクションSHOULDは輸送失敗が起こるようにするTU、および直接「終えられた」状態へのクライアントトランザクションSHOULD変遷を知らせます。 TUは[4]で説明されたフェイルオーバーメカニズムを扱うでしょう。

17.2 Server Transaction

17.2 サーバトランザクション

   The server transaction is responsible for the delivery of requests to
   the TU and the reliable transmission of responses.  It accomplishes
   this through a state machine.  Server transactions are created by the
   core when a request is received, and transaction handling is desired
   for that request (this is not always the case).

サーバトランザクションはTUへの要求の配送と応答の信頼できる送信に原因となります。 それは州のマシンを通してこれを達成します。 要求が受信されているとき、サーバトランザクションはコアによって作成されます、そして、トランザクション取り扱いはその要求のために望まれています(これはいつもそうであるというわけではありません)。

   As with the client transactions, the state machine depends on whether
   the received request is an INVITE request.

クライアントトランザクションのように、州のマシンは受信された要求がINVITE要求であるかどうかによります。

17.2.1 INVITE Server Transaction

17.2.1 サーバトランザクションを招待してください。

   The state diagram for the INVITE server transaction is shown in
   Figure 7.

INVITEサーバトランザクションのための州のダイヤグラムは図7で見せられます。

   When a server transaction is constructed for a request, it enters the
   "Proceeding" state.  The server transaction MUST generate a 100
   (Trying) response unless it knows that the TU will generate a
   provisional or final response within 200 ms, in which case it MAY
   generate a 100 (Trying) response.  This provisional response is
   needed to quench request retransmissions rapidly in order to avoid
   network congestion.  The 100 (Trying) response is constructed
   according to the procedures in Section 8.2.6, except that the
   insertion of tags in the To header field of the response (when none
   was present in the request) is downgraded from MAY to SHOULD NOT.
   The request MUST be passed to the TU.

サーバトランザクションが要求のために構成されるとき、それは「進行」状態に入ります。 TUが200msの中で暫定的であるか最終的な応答を生成するのを知らない場合、サーバトランザクションは100の(試みること)の応答を生成しなければなりません、その場合、それは100の(試みること)の応答を生成するかもしれません。 この暫定的な応答が、ネットワークの混雑を避けるために急速に要求「再-トランスミッション」を冷却するのに必要です。 セクション8.2.6における手順によると、100の(試みること)の応答は構成されます、応答(なにも要求に存在していなかったとき)のToヘッダーフィールドへのタグの挿入が5月からSHOULD NOTに格下げされるのを除いて。 要求にTUに合格しなければなりません。

   The TU passes any number of provisional responses to the server
   transaction.  So long as the server transaction is in the
   "Proceeding" state, each of these MUST be passed to the transport
   layer for transmission.  They are not sent reliably by the
   transaction layer (they are not retransmitted by it) and do not cause
   a change in the state of the server transaction.  If a request
   retransmission is received while in the "Proceeding" state, the most
   recent provisional response that was received from the TU MUST be
   passed to the transport layer for retransmission.  A request is a
   retransmission if it matches the same server transaction based on the
   rules of Section 17.2.3.

TUはサーバトランザクションへのいろいろな暫定的な応答を通過します。 サーバトランザクションが「進行」状態にある限り、トランスミッションのためにそれぞれのこれらをトランスポート層に通過しなければなりません。 彼らは、トランザクション層(それらはそれによって再送されない)のそばで確かに送られないで、またサーバトランザクションの状態で変化を引き起こしません。 「再-トランスミッション」のために「進行」状態でトゥから受けられた最新の暫定的な応答をトランスポート層に通過しなければなりませんが、要求「再-トランスミッション」が受け取られているなら。 セクション17.2.3の規則に基づく同じサーバトランザクションを合わせるなら、要求は「再-トランスミッション」です。

   If, while in the "Proceeding" state, the TU passes a 2xx response to
   the server transaction, the server transaction MUST pass this
   response to the transport layer for transmission.  It is not

TUが「進行」状態でサーバトランザクションへの2xx応答を通過している間、サーバトランザクションがトランスミッションのためにトランスポート層へのこの応答を通過しなければならないなら。 それはそうではありません。

Rosenberg, et. al.          Standards Track                   [Page 134]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[134ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   retransmitted by the server transaction; retransmissions of 2xx
   responses are handled by the TU.  The server transaction MUST then
   transition to the "Terminated" state.

サーバトランザクションで、再送されます。 2xx応答の「再-トランスミッション」はTUによって扱われます。 サーバトランザクションは次に、「終えられた」状態への変遷がそうしなければなりません。

   While in the "Proceeding" state, if the TU passes a response with
   status code from 300 to 699 to the server transaction, the response
   MUST be passed to the transport layer for transmission, and the state
   machine MUST enter the "Completed" state.  For unreliable transports,
   timer G is set to fire in T1 seconds, and is not set to fire for
   reliable transports.

TUがステータスコードで300〜699までサーバトランザクションに応答を通過するなら、「進行」状態では、トランスミッションのために応答をトランスポート層に通過しなければなりません、そして、州のマシンは「完成した」状態に入れなければなりませんが。 頼り無い輸送において、タイマGは、T1秒に発火するように設定されて、信頼できる輸送のために発火するように設定されません。

      This is a change from RFC 2543, where responses were always
      retransmitted, even over reliable transports.

これはRFC2543からの変化です。そこでは、応答がいつも信頼できる輸送の上にさえ再送されました。

   When the "Completed" state is entered, timer H MUST be set to fire in
   64*T1 seconds for all transports.  Timer H determines when the server
   transaction abandons retransmitting the response.  Its value is
   chosen to equal Timer B, the amount of time a client transaction will
   continue to retry sending a request.  If timer G fires, the response
   is passed to the transport layer once more for retransmission, and
   timer G is set to fire in MIN(2*T1, T2) seconds.  From then on, when
   timer G fires, the response is passed to the transport again for
   transmission, and timer G is reset with a value that doubles, unless
   that value exceeds T2, in which case it is reset with the value of
   T2.  This is identical to the retransmit behavior for requests in the
   "Trying" state of the non-INVITE client transaction.  Furthermore,
   while in the "Completed" state, if a request retransmission is
   received, the server SHOULD pass the response to the transport for
   retransmission.

「完成した」状態が入られるとき、64*T1秒にすべての輸送のために発火するようにタイマHを設定しなければなりません。 応答を再送するサーバトランザクション放棄であるときにHが決定するタイマ。 値はTimer Bと等しいように選ばれています、クライアントトランザクションが、要求を送りながら再試行し続ける時間に。 タイマGが撃たれるなら、応答はもう一度「再-トランスミッション」のためにトランスポート層に通過されます、そして、タイマGがMIN(2*T1、T2)秒に発火するように設定されます。 タイマG炎、応答がトランスミッションのために再び輸送に通過されて、タイマGが倍増する値でリセットされるとき、それ以来、その場合、その値がT2を超えていない場合、それはT2の値でリセットされます。 これが同じである、非INVITEクライアントトランザクションの「試みている」状態での要求のための振舞いを再送してください。 その上、要求「再-トランスミッション」が受け取られているなら、サーバSHOULDは「再-トランスミッション」のために「完成した」状態にある間、輸送への応答を通過します。

   If an ACK is received while the server transaction is in the
   "Completed" state, the server transaction MUST transition to the
   "Confirmed" state.  As Timer G is ignored in this state, any
   retransmissions of the response will cease.

サーバトランザクションが「完成した」状態にありますが、ACKが受け取られているなら、サーバトランザクションは「確認された」状態への変遷を受け取られていさせなければなりません。 Timer Gがこの状態で無視されるとき、応答のどんな「再-トランスミッション」もやむでしょう。

   If timer H fires while in the "Completed" state, it implies that the
   ACK was never received.  In this case, the server transaction MUST
   transition to the "Terminated" state, and MUST indicate to the TU
   that a transaction failure has occurred.

「完成した」状態でACKが決して受け取られなかったのを含意している間、タイマHが撃たれるなら。 この場合、サーバトランザクションは、「終えられた」状態に移行しなければならなくて、トランザクション失敗が起こったのをTUに示さなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 135]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[135ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |
            300-699 from TU |     |2xx from TU        |
            send response   |     |send response      |
                            |     +------------------>+
                            |                         |
            INVITE          V          Timer G fires  |
            send response+-----------+ send response  |
                +--------|           |--------+       |
                |        | Completed |        |       |
                +------->|           |<-------+       |
                         +-----------+                |
                            |     |                   |
                        ACK |     |                   |
                        -   |     +------------------>+
                            |        Timer H fires    |
                            V        or Transport Err.|
                         +-----------+  Inform TU     |
                         |           |                |
                         | Confirmed |                |
                         |           |                |
                         +-----------+                |
                               |                      |
                               |Timer I fires         |
                               |-                     |
                               |                      |
                               V                      |
                         +-----------+                |
                         |           |                |
                         | Terminated|<---------------+
                         |           |
                         +-----------+

| 招待|TUが200msで応答+を送らないなら、TU INVITE VへのパスINVは100を送ります。-----------+ +--------| |--------+101-199 TUから| | 進行| |応答+を送ってください。------->| | <、-、-、-、-、-、--+ | | 輸送は間違えます。 | | TUに知らせてください。| |--------------->++-----------+ | 300-699 TUから| |TUからの2xx| 応答を送ってください。| |応答を送ってください。| | +------------------>+| | INVITE V Timer G炎| 応答+を送ってください。-----------+は応答を送ります。| +--------| |--------+ | | | 完成されます。| | | +------->| | <、-、-、-、-、-、--+ | +-----------+ | | | | ACK| | | - | +------------------>+| タイマH炎| Vか輸送が間違える、| +-----------+はTUに知らせます。| | | | | 確認されます。| | | | | +-----------+ | | | |私が撃つタイマ| |- | | | V| +-----------+ | | | | | 終わります。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | +-----------+

              Figure 7: INVITE server transaction

図7: INVITEサーバトランザクション

Rosenberg, et. al.          Standards Track                   [Page 136]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[136ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The purpose of the "Confirmed" state is to absorb any additional ACK
   messages that arrive, triggered from retransmissions of the final
   response.  When this state is entered, timer I is set to fire in T4
   seconds for unreliable transports, and zero seconds for reliable
   transports.  Once timer I fires, the server MUST transition to the
   "Terminated" state.

「確認された」状態の目的は到着するどんな追加ACKメッセージも吸収することです、最終的な応答の「再-トランスミッション」から引き起こされて。 この状態が入られるとき、タイマは、頼り無い輸送のためのT4秒に炎を始めて、信頼できる輸送のために秒は全く始めませんでした。 一度、私が撃つタイマ、サーバは「終えられた」状態への変遷がそうしなければなりません。

   Once the transaction is in the "Terminated" state, it MUST be
   destroyed immediately.  As with client transactions, this is needed
   to ensure reliability of the 2xx responses to INVITE.

トランザクションが「終えられた」状態にいったんあると、すぐに、それを破壊しなければなりません。 クライアントトランザクションのように、これが、INVITEへの2xx応答の信頼性を確実にするのに必要です。

17.2.2 Non-INVITE Server Transaction

17.2.2 非招待サーバトランザクション

   The state machine for the non-INVITE server transaction is shown in
   Figure 8.

非INVITEサーバトランザクションのための州のマシンは図8で見せられます。

   The state machine is initialized in the "Trying" state and is passed
   a request other than INVITE or ACK when initialized.  This request is
   passed up to the TU.  Once in the "Trying" state, any further request
   retransmissions are discarded.  A request is a retransmission if it
   matches the same server transaction, using the rules specified in
   Section 17.2.3.

州のマシンは「試みている」状態で初期化されて、初期化されると、INVITEかACKを除いて、要求に合格します。 この要求はTUまで合格されます。 「試みている」状態の一度、「再-トランスミッション」が捨てられるようこれ以上要求してください。 セクション17.2.3で指定された規則を使用して、同じサーバトランザクションを合わせるなら、要求は「再-トランスミッション」です。

   While in the "Trying" state, if the TU passes a provisional response
   to the server transaction, the server transaction MUST enter the
   "Proceeding" state.  The response MUST be passed to the transport
   layer for transmission.  Any further provisional responses that are
   received from the TU while in the "Proceeding" state MUST be passed
   to the transport layer for transmission.  If a retransmission of the
   request is received while in the "Proceeding" state, the most
   recently sent provisional response MUST be passed to the transport
   layer for retransmission.  If the TU passes a final response (status
   codes 200-699) to the server while in the "Proceeding" state, the
   transaction MUST enter the "Completed" state, and the response MUST
   be passed to the transport layer for transmission.

TUがサーバトランザクションへの暫定的な応答を通過するなら、サーバトランザクションは「試みている」状態で「進行」状態に入らなければなりませんが。 トランスミッションのために応答をトランスポート層に通過しなければなりません。 これ以上、トランスミッションのために「進行」状態にある間にTUから受けられる暫定的な応答をトランスポート層に通過しなければなりません。 「再-トランスミッション」のために「進行」状態で最も最近送られた暫定的な応答をトランスポート層に通過しなければなりませんが、要求の「再-トランスミッション」が受け取られているなら。 TUが通るなら、トランスミッションのために、トランザクションが「完成した」状態、および応答を「進行」状態に入れなければならない間のサーバへの最終的な応答(ステータスコード200-699)をトランスポート層に通過しなければなりません。

   When the server transaction enters the "Completed" state, it MUST set
   Timer J to fire in 64*T1 seconds for unreliable transports, and zero
   seconds for reliable transports.  While in the "Completed" state, the
   server transaction MUST pass the final response to the transport
   layer for retransmission whenever a retransmission of the request is
   received.  Any other final responses passed by the TU to the server
   transaction MUST be discarded while in the "Completed" state.  The
   server transaction remains in this state until Timer J fires, at
   which point it MUST transition to the "Terminated" state.

サーバトランザクションが「完成した」状態に入るとき、それは、Timer Jに64*T1秒に信頼できる輸送のために頼り無い輸送にもかかわらず、どんな秒間も、発火しないように設定しなければなりません。 要求の「再-トランスミッション」が受け取られているときはいつも、サーバトランザクションは「再-トランスミッション」のために「完成した」状態でトランスポート層への最終的な応答を通過しなければなりませんが。 「完成した」状態にある間、TUによってサーバトランザクションに通過されたいかなる他の最終的な応答も捨てなければなりません。 Timer Jが「終えられた」状態への変遷をそれはどのポイントがそうしなければならないかに発火させるまで、サーバトランザクションがこの州に残っています。

   The server transaction MUST be destroyed the instant it enters the
   "Terminated" state.

「終えられた」状態に入るとすぐに、サーバトランザクションを破壊しなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 137]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[137ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

17.2.3 Matching Requests to Server Transactions

17.2.3 サーバトランザクションへの合っている要求

   When a request is received from the network by the server, it has to
   be matched to an existing transaction.  This is accomplished in the
   following manner.

サーバでネットワークから要求を受け取るとき、既存のトランザクションにそれを合わせなければなりません。 これは以下の方法で達成されます。

   The branch parameter in the topmost Via header field of the request
   is examined.  If it is present and begins with the magic cookie
   "z9hG4bK", the request was generated by a client transaction
   compliant to this specification.  Therefore, the branch parameter
   will be unique across all transactions sent by that client.  The
   request matches a transaction if:

要求の最上のViaヘッダーフィールドにおけるブランチパラメタは調べられます。 存在していて、魔法のクッキー"z9hG4bK"と共に始まるなら、要求はこの仕様への対応することのクライアントトランザクションによって生成されました。 したがって、ブランチパラメタはそのクライアントによって送られたすべてのトランザクションの向こう側にユニークになるでしょう。 要求がトランザクションに合っている、:

      1. the branch parameter in the request is equal to the one in the
         top Via header field of the request that created the
         transaction, and

そして1. 要求におけるブランチパラメタがトランザクションを作成した要求のトップViaヘッダーフィールドにおけるものと等しい。

      2. the sent-by value in the top Via of the request is equal to the
         one in the request that created the transaction, and

2. 発信しているのは中で先端を評価します。そして要求のViaがトランザクションを作成した要求におけるものと等しい。

      3. the method of the request matches the one that created the
         transaction, except for ACK, where the method of the request
         that created the transaction is INVITE.

3. 要求のメソッドはトランザクションを作成したものに合っています、ACKを除いて。そこでは、トランザクションを作成した要求のメソッドがINVITEです。

   This matching rule applies to both INVITE and non-INVITE transactions
   alike.

この合っている規則は同じくINVITEと非INVITEトランザクションの両方に適用されます。

      The sent-by value is used as part of the matching process because
      there could be accidental or malicious duplication of branch
      parameters from different clients.

マッチング過程の一部として、異なったクライアントからのブランチパラメタの偶然の、または、悪意がある複製があるかもしれないので、使用されます発信しているのが、評価する。

   If the branch parameter in the top Via header field is not present,
   or does not contain the magic cookie, the following procedures are
   used.  These exist to handle backwards compatibility with RFC 2543
   compliant implementations.

トップViaヘッダーフィールドにおけるブランチパラメタが存在していないか、または魔法のクッキーを含んでいないなら、以下の手順は使用されています。 これらは、後方にRFC2543対応することの実装との互換性を扱うために存在しています。

   The INVITE request matches a transaction if the Request-URI, To tag,
   From tag, Call-ID, CSeq, and top Via header field match those of the
   INVITE request which created the transaction.  In this case, the
   INVITE is a retransmission of the original one that created the
   transaction.  The ACK request matches a transaction if the Request-
   URI, From tag, Call-ID, CSeq number (not the method), and top Via
   header field match those of the INVITE request which created the
   transaction, and the To tag of the ACK matches the To tag of the
   response sent by the server transaction.  Matching is done based on
   the matching rules defined for each of those header fields.
   Inclusion of the tag in the To header field in the ACK matching
   process helps disambiguate ACK for 2xx from ACK for other responses

Request-URI、Toタグ、Fromタグ、Call-ID、CSeq、およびトップViaヘッダーフィールドがトランザクションを作成したINVITE要求のものに合っているなら、INVITE要求はトランザクションに合っています。 この場合、INVITEはトランザクションを作成したオリジナルのものの「再-トランスミッション」です。 Request URI、Fromタグ、Call-ID、CSeq番号(メソッドでない)、およびトップViaヘッダーフィールドがトランザクションを作成したINVITE要求のもの、および応答のToタグがサーバトランザクションで送ったACKマッチのToタグに合っているなら、ACK要求はトランザクションに合っています。 それぞれのそれらのヘッダーフィールドのために定義された合っている規則に基づいて、マッチングします。 ACKマッチング過程によるToヘッダーフィールドでのタグの包含は、2xxのために他の応答のためのACKからACKのあいまいさを除くのを助けます。

Rosenberg, et. al.          Standards Track                   [Page 138]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[138ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   at a proxy, which may have forwarded both responses (This can occur
   in unusual conditions.  Specifically, when a proxy forked a request,
   and then crashes, the responses may be delivered to another proxy,
   which might end up forwarding multiple responses upstream).  An ACK
   request that matches an INVITE transaction matched by a previous ACK
   is considered a retransmission of that previous ACK.

プロキシで。(プロキシは両方の応答を進めたかもしれません)。(これは珍しい状態で起こることができます。 プロキシが要求を分岐させて、次に、ダウンするとき、明確に、応答は別のプロキシに提供されるかもしれません。(プロキシは結局、複数の応答上流を進めるかもしれません)。). 前のACKによって合われていたINVITEトランザクションに合っているACK要求はその前のACKの「再-トランスミッション」であると考えられます。

Rosenberg, et. al.          Standards Track                   [Page 139]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[139ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

                                  |Request received
                                  |pass to TU
                                  V
                            +-----------+
                            |           |
                            | Trying    |-------------+
                            |           |             |
                            +-----------+             |200-699 from TU
                                  |                   |send response
                                  |1xx from TU        |
                                  |send response      |
                                  |                   |
               Request            V      1xx from TU  |
               send response+-----------+send response|
                   +--------|           |--------+    |
                   |        | Proceeding|        |    |
                   +------->|           |<-------+    |
            +<--------------|           |             |
            |Trnsprt Err    +-----------+             |
            |Inform TU            |                   |
            |                     |                   |
            |                     |200-699 from TU    |
            |                     |send response      |
            |  Request            V                   |
            |  send response+-----------+             |
            |      +--------|           |             |
            |      |        | Completed |<------------+
            |      +------->|           |
            +<--------------|           |
            |Trnsprt Err    +-----------+
            |Inform TU            |
            |                     |Timer J fires
            |                     |-
            |                     |
            |                     V
            |               +-----------+
            |               |           |
            +-------------->| Terminated|
                            |           |
                            +-----------+

| 要求は受信されました。|TU V+に通ってください。-----------+ | | | 試みます。|-------------+ | | | +-----------+ |200-699 TUから| |応答を送ってください。|TUからの1xx| |応答を送ってください。| | | TUからV1xxを要求してください。| 応答+を送ってください。-----------+は応答を送ります。| +--------| |--------+ | | | 進行| | | +------->| | <、-、-、-、-、-、--+ | + <。--------------| | | |Trnsprtが間違える、+-----------+ | |TUに知らせてください。| | | | | | |200-699 TUから| | |応答を送ってください。| | Vを要求してください。| | 応答+を送ってください。-----------+ | | +--------| | | | | | 完成されます。| <、-、-、-、-、-、-、-、-、-、-、--+ | +------->|、| + <。--------------| | |Trnsprtが間違える、+-----------+ |TUに知らせてください。| | |タイマJ炎| |- | | | V| +-----------+ | | | +-------------->| 終わります。| | | +-----------+

                Figure 8: non-INVITE server transaction

エイト環: 非INVITEサーバトランザクション

   For all other request methods, a request is matched to a transaction
   if the Request-URI, To tag, From tag, Call-ID, CSeq (including the
   method), and top Via header field match those of the request that
   created the transaction.  Matching is done based on the matching

他のすべての要求メソッドにおいて、Request-URI、Toタグ、Fromタグ、Call-ID、CSeq(メソッドを含んでいる)、およびトップViaヘッダーフィールドがトランザクションを作成した要求のものに合うなら、要求はトランザクションに合われています。 マッチングに基づいて、マッチングします。

Rosenberg, et. al.          Standards Track                   [Page 140]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[140ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   rules defined for each of those header fields.  When a non-INVITE
   request matches an existing transaction, it is a retransmission of
   the request that created that transaction.

それぞれのそれらのヘッダーフィールドのために定義された規則。 非INVITE要求が既存のトランザクションに合っているとき、それはそのトランザクションを作成した要求の「再-トランスミッション」です。

   Because the matching rules include the Request-URI, the server cannot
   match a response to a transaction.  When the TU passes a response to
   the server transaction, it must pass it to the specific server
   transaction for which the response is targeted.

合っている規則がRequest-URIを含んでいるので、サーバはトランザクションへの応答に合うことができません。 TUがサーバトランザクションへの応答を通過するとき、それは応答が狙う特定のサーバトランザクションにそれを通過しなければなりません。

17.2.4 Handling Transport Errors

17.2.4 取り扱い輸送誤り

   When the server transaction sends a response to the transport layer
   to be sent, the following procedures are followed if the transport
   layer indicates a failure.

サーバトランザクションが送られるトランスポート層への応答を送ると、トランスポート層が失敗を示すなら、以下の手順は従われています。

   First, the procedures in [4] are followed, which attempt to deliver
   the response to a backup.  If those should all fail, based on the
   definition of failure in [4], the server transaction SHOULD inform
   the TU that a failure has occurred, and SHOULD transition to the
   terminated state.

まず最初に、[4]の手順(バックアップへの応答を提供するのを試みる)は従われています。 それらであるなら、すべてが[4]との失敗の定義に基づいてサーバトランザクションSHOULDに失敗するなら、失敗が起こるのとSHOULD変遷を終えられた状態に持っていることをTUに知らせてください。

18 Transport

18 輸送

   The transport layer is responsible for the actual transmission of
   requests and responses over network transports.  This includes
   determination of the connection to use for a request or response in
   the case of connection-oriented transports.

トランスポート層はネットワーク輸送の上の要求と応答の実際の送信に原因となります。 これは要求か応答に接続指向の輸送の場合に使用する接続の決断を含んでいます。

   The transport layer is responsible for managing persistent
   connections for transport protocols like TCP and SCTP, or TLS over
   those, including ones opened to the transport layer.  This includes
   connections opened by the client or server transports, so that
   connections are shared between client and server transport functions.
   These connections are indexed by the tuple formed from the address,
   port, and transport protocol at the far end of the connection.  When
   a connection is opened by the transport layer, this index is set to
   the destination IP, port and transport.  When the connection is
   accepted by the transport layer, this index is set to the source IP
   address, port number, and transport.  Note that, because the source
   port is often ephemeral, but it cannot be known whether it is
   ephemeral or selected through procedures in [4], connections accepted
   by the transport layer will frequently not be reused.  The result is
   that two proxies in a "peering" relationship using a connection-
   oriented transport frequently will have two connections in use, one
   for transactions initiated in each direction.

トランスポート層はTCPとSCTPのようなトランスポート・プロトコル、またはそれらの上のTLSのためにパーシステントコネクションを管理するのに原因となります、トランスポート層に開かれたものを含んでいて。 これはクライアントによって開かれた接続かサーバ輸送を含んでいます、接続がクライアントとサーバ輸送機能の間で共有されるように。 これらの接続はアドレス、ポート、およびトランスポート・プロトコルから接続の遠端で形成されたtupleによって索引をつけられます。 接続がトランスポート層によって開かれるとき、このインデックスは目的地IP、ポート、および輸送に設定されます。 トランスポート層のそばで接続を受け入れるとき、ソースIPアドレス、ポートナンバー、および輸送にこのインデックスを設定します。 トランスポート層で受け入れられた接続がソースポートがしばしばはかないのですが、それがはかないか[4]の手順で選択されているか知ることができないので頻繁に再利用されないことに注意してください。 結果は接続指向の輸送を使用する「じっと見る」関係における2つのプロキシには使用(各方向に開始されたトランザクションのためのもの)における2つの接続が頻繁にあるということです。

Rosenberg, et. al.          Standards Track                   [Page 141]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[141ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   It is RECOMMENDED that connections be kept open for some
   implementation-defined duration after the last message was sent or
   received over that connection.  This duration SHOULD at least equal
   the longest amount of time the element would need in order to bring a
   transaction from instantiation to the terminated state.  This is to
   make it likely that transactions are completed over the same
   connection on which they are initiated (for example, request,
   response, and in the case of INVITE, ACK for non-2xx responses).
   This usually means at least 64*T1 (see Section 17.1.1.1 for a
   definition of T1).  However, it could be larger in an element that
   has a TU using a large value for timer C (bullet 11 of Section 16.6),
   for example.

その接続の上に最後のメッセージを送ったか、または受け取った後に何らかの実装で定義された持続時間において開くように接続を保つのは、RECOMMENDEDです。 この持続時間SHOULDは要素が具体化から終えられた状態にトランザクションをもたらすのに必要である中で最も長い時間と少なくとも等しいです。 これが取引がそれらが開始されるのと同じ接続に完了されるのをありそうにするためのものである、(例えば、要求、応答、INVITE、非2xx応答のためのACKに関するケース、) 通常、これが少なくとも64*T1を意味する、(セクション17.1.1を見てください、T1の定義のための.1) しかしながら、例えば、タイマC(セクション16.6の弾丸11)に大きい値を使用することでTUを持っている要素では、それは、より大きいかもしれません。

   All SIP elements MUST implement UDP and TCP.  SIP elements MAY
   implement other protocols.

すべてのSIP要素がUDPとTCPを実装しなければなりません。 SIP要素は他のプロトコルを実装するかもしれません。

      Making TCP mandatory for the UA is a substantial change from RFC
      2543.  It has arisen out of the need to handle larger messages,
      which MUST use TCP, as discussed below.  Thus, even if an element
      never sends large messages, it may receive one and needs to be
      able to handle them.

TCPをUAに義務的にするのは、RFC2543からの大きな変化です。 それは以下で議論するようにTCPを使用しなければならないより大きいメッセージを扱う必要性から起こりました。 したがって、要素が大きいメッセージを決して送らないでも、それは、1を受け取るかもしれなくて、それらを扱うことができる必要があります。

18.1 Clients

18.1 クライアント

18.1.1 Sending Requests

18.1.1 送付要求

   The client side of the transport layer is responsible for sending the
   request and receiving responses.  The user of the transport layer
   passes the client transport the request, an IP address, port,
   transport, and possibly TTL for multicast destinations.

トランスポート層のクライアント側面は要求を送って、応答を受けるのに原因となります。 トランスポート層のユーザはクライアント輸送の要求、IPアドレス、ポート、輸送、およびことによるとTTLをマルチキャストの目的地に通り過ぎます。

   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.

経路MTUの200バイト以内で要求があるか、それが1300バイトより大きく、または経路MTUが未知であるなら、要求にRFC2914の[43]の混雑の制御トランスポート・プロトコルを使用させなければなりません、TCPなどのように。 これが最高Viaで示されたものからトランスポート・プロトコルにおける変化を引き起こすなら、最高Viaの値を変えなければなりません。 これは、UDPの上でメッセージの断片化を防いで、より大きいメッセージに輻輳制御を提供します。 しかしながら、実装はメッセージを最大のデータグラムパケットサイズまで扱うことができなければなりません。 UDPに関しては、このサイズはIPとUDPヘッダーを含む6万5535バイトです。

      The 200 byte "buffer" between the message size and the MTU
      accommodates the fact that the response in SIP can be larger than
      the request.  This happens due to the addition of Record-Route
      header field values to the responses to INVITE, for example.  With
      the extra buffer, the response can be about 170 bytes larger than
      the request, and still not be fragmented on IPv4 (about 30 bytes

メッセージサイズとMTUの間の200バイト「バッファ」はSIPの応答が要求より大きい場合があるという事実に対応します。 これはRecord-ルートヘッダーフィールド値の追加のため例えば、INVITEへの応答に起こります。 付加的なバッファで、応答は要求よりおよそ170バイト大きく、IPv4でまだ断片化できない、(およそ30バイト

Rosenberg, et. al.          Standards Track                   [Page 142]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[142ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
      path MTU is not known, based on the assumption of a 1500 byte
      Ethernet MTU.

IP/UDPによって消費されて、IPSecを全く仮定しません) 1300は経路であるときに、選ばれて、MTUが1500年のバイトのイーサネットMTUの仮定に基づいて知られていないということです。

   If an element sends a request over TCP because of these message size
   constraints, and that request would have otherwise been sent over
   UDP, if the attempt to establish the connection generates either an
   ICMP Protocol Not Supported, or results in a TCP reset, the element
   SHOULD retry the request, using UDP.  This is only to provide
   backwards compatibility with RFC 2543 compliant implementations that
   do not support TCP.  It is anticipated that this behavior will be
   deprecated in a future revision of this specification.

要素がこれらのメッセージサイズ規制のためにTCPの上に要求を送って、そうでなければ、その要求をUDPの上に送ったなら、接続を確立する試みがICMPプロトコルNot SupportedかTCPリセットにおける結果のどちらかを生成するなら、要素SHOULDは要求を再試行します、UDPを使用して。 これは、TCPをサポートしないRFC2543対応することの実装との互換性を後方に提供するためのだけものです。 この振舞いがこの仕様の今後の改正で推奨しなくなると予期されます。

   A client that sends a request to a multicast address MUST add the
   "maddr" parameter to its Via header field value containing the
   destination multicast address, and for IPv4, SHOULD add the "ttl"
   parameter with a value of 1.  Usage of IPv6 multicast is not defined
   in this specification, and will be a subject of future
   standardization when the need arises.

マルチキャストアドレスに要求を送るクライアントは送付先マルチキャストアドレスを含むViaヘッダーフィールド価値に"maddr"パラメタを加えなければなりません、そして、IPv4に関して、SHOULDは1の値で"ttl"パラメタを加えます。 IPv6マルチキャストの用法は、この仕様に基づき定義されないで、必要性が起こるとき、今後の標準化の対象になるでしょう。

   These rules result in a purposeful limitation of multicast in SIP.
   Its primary function is to provide a "single-hop-discovery-like"
   service, delivering a request to a group of homogeneous servers,
   where it is only required to process the response from any one of
   them.  This functionality is most useful for registrations.  In fact,
   based on the transaction processing rules in Section 17.1.3, the
   client transaction will accept the first response, and view any
   others as retransmissions because they all contain the same Via
   branch identifier.

これらの規則はSIPでのマルチキャストの故意の制限をもたらします。 プライマリ機能は「ただ一つのホップ発見のような」サービスを提供することです、それがそれらのどれかから応答を処理するのに必要であるだけである同次のサーバのグループに要求を提供して。 この機能性は登録証明書の最も役に立ちます。 事実上、セクション17.1.3におけるトランザクション処理規則に基づいて、彼らが皆、同じViaブランチ識別子を含むので、クライアントトランザクションは、最初の応答を受け入れて、どんな他のものも「再-トランスミッション」であるとみなすでしょう。

   Before a request is sent, the client transport MUST insert a value of
   the "sent-by" field into the Via header field.  This field contains
   an IP address or host name, and port.  The usage of an FQDN is
   RECOMMENDED.  This field is used for sending responses under certain
   conditions, described below.  If the port is absent, the default
   value depends on the transport.  It is 5060 for UDP, TCP and SCTP,
   5061 for TLS.

要求を送る前に、クライアント輸送は「送って」分野の値をViaヘッダーフィールドに挿入しなければなりません。 この分野はIPアドレスかホスト名と、ポートを含んでいます。 FQDNの使用法はRECOMMENDEDです。 この分野は、以下で説明されたある状態の下に応答を送るのに使用されます。 ポートが欠けるなら、デフォルト値は輸送に依存します。 それは、TLSのためのUDPのための5060とTCPとSCTP、5061です。

   For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.  Under error conditions, the
   server may attempt to open a new connection to send the response.  To
   handle this case, the transport layer MUST also be prepared to
   receive an incoming connection on the source IP address from which
   the request was sent and port number in the "sent-by" field.  It also

信頼できる輸送において、通常、要求が受け取られた接続に応答を送ります。 したがって、要求を送るのに使用される同じ接続のときに応答を受けるようにクライアント輸送を準備しなければなりません。 エラー条件の下では、サーバは、応答を送るために新しい接続を開くのを試みるかもしれません。 また、本件を扱うために、要求が送られたソースIPアドレスにおける接続要求と「送って」分野のポートナンバーを受けるようにトランスポート層を準備しなければなりません。 それも

Rosenberg, et. al.          Standards Track                   [Page 143]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[143ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   MUST be prepared to receive incoming connections on any address and
   port that would be selected by a server based on the procedures
   described in Section 5 of [4].

[4]のセクション5で説明された手順に基づくサーバによって選択されるどんなアドレスとポートの上でも接続要求を受けるように準備しなければなりません。

   For unreliable unicast transports, the client transport MUST be
   prepared to receive responses on the source IP address from which the
   request is sent (as responses are sent back to the source address)
   and the port number in the "sent-by" field.  Furthermore, as with
   reliable transports, in certain cases the response will be sent
   elsewhere.  The client MUST be prepared to receive responses on any
   address and port that would be selected by a server based on the
   procedures described in Section 5 of [4].

頼り無いユニキャスト輸送のために、「送って」分野で要求が送られる(ソースアドレスが応答に送り返されるとき)ソースIPアドレスとポートナンバーで応答を受けるようにクライアント輸送を準備しなければなりません。 その上、ある場合には、信頼できる輸送の場合、応答をほかの場所に送るでしょう。 クライアントは[4]のセクション5で説明された手順に基づくサーバによって選択されるどんなアドレスとポートの上でも応答を受ける用意ができていなければなりません。

   For multicast, the client transport MUST be prepared to receive
   responses on the same multicast group and port to which the request
   is sent (that is, it needs to be a member of the multicast group it
   sent the request to.)

マルチキャストのために、同じマルチキャストグループと要求が送られるポートの上で応答を受けるようにクライアント輸送を準備しなければなりません。(すなわち、それは、それが要求を送ったマルチキャストグループのメンバーである必要があります。)

   If a request is destined to an IP address, port, and transport to
   which an existing connection is open, it is RECOMMENDED that this
   connection be used to send the request, but another connection MAY be
   opened and used.

要求が既存の接続がオープンであるIPアドレス、ポート、および輸送に運命づけられているなら、この接続が要求を送るのに使用されるのが、RECOMMENDEDですが、別の接続は、開かれて、使用されるかもしれません。

   If a request is sent using multicast, it is sent to the group
   address, port, and TTL provided by the transport user.  If a request
   is sent using unicast unreliable transports, it is sent to the IP
   address and port provided by the transport user.

要求にマルチキャストを使用させるなら、輸送ユーザによって提供されたグループアドレス、ポート、およびTTLにそれを送ります。 要求にユニキャストの頼り無い輸送を使用させるなら、輸送ユーザによって提供されたIPアドレスとポートにそれを送ります。

18.1.2 Receiving Responses

18.1.2 応答を受けること。

   When a response is received, the client transport examines the top
   Via header field value.  If the value of the "sent-by" parameter in
   that header field value does not correspond to a value that the
   client transport is configured to insert into requests, the response
   MUST be silently discarded.

応答が受け取られているとき、クライアント輸送は最高Viaヘッダーフィールド価値を調べます。 そのヘッダーフィールド値における、「送って」パラメタの値がクライアント輸送が要求に挿入するために構成される値と食い違っているなら、静かに応答を捨てなければなりません。

   If there are any client transactions in existence, the client
   transport uses the matching procedures of Section 17.1.3 to attempt
   to match the response to an existing transaction.  If there is a
   match, the response MUST be passed to that transaction.  Otherwise,
   the response MUST be passed to the core (whether it be stateless
   proxy, stateful proxy, or UA) for further processing.  Handling of
   these "stray" responses is dependent on the core (a proxy will
   forward them, while a UA will discard, for example).

何か現存するクライアントトランザクションがあれば、クライアント輸送は、既存のトランザクションへの応答に合っているのを試みるのにセクション17.1.3の合っている手順を用います。 マッチがあれば、そのトランザクションに応答を通過しなければなりません。 さもなければ、さらなる処理のためにコア(それが状態がないプロキシ、statefulプロキシ、またはUAであることにかかわらず)に応答を通過しなければなりません。 これらの「迷っている」応答の取り扱いはコアに依存しています(プロキシがそれらを進めるでしょう、例えば、UAが捨てるでしょうが)。

Rosenberg, et. al.          Standards Track                   [Page 144]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[144ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

18.2 Servers

18.2 サーバ

18.2.1 Receiving Requests

18.2.1 要求を受け取ること。

   A server SHOULD be prepared to receive requests on any IP address,
   port and transport combination that can be the result of a DNS lookup
   on a SIP or SIPS URI [4] that is handed out for the purposes of
   communicating with that server.  In this context, "handing out"
   includes placing a URI in a Contact header field in a REGISTER
   request or a redirect response, or in a Record-Route header field in
   a request or response.  A URI can also be "handed out" by placing it
   on a web page or business card.  It is also RECOMMENDED that a server
   listen for requests on the default SIP ports (5060 for TCP and UDP,
   5061 for TLS over TCP) on all public interfaces.  The typical
   exception would be private networks, or when multiple server
   instances are running on the same host.  For any port and interface
   that a server listens on for UDP, it MUST listen on that same port
   and interface for TCP.  This is because a message may need to be sent
   using TCP, rather than UDP, if it is too large.  As a result, the
   converse is not true.  A server need not listen for UDP on a
   particular address and port just because it is listening on that same
   address and port for TCP.  There may, of course, be other reasons why
   a server needs to listen for UDP on a particular address and port.

サーバSHOULDがどんなIPアドレスに関する要求も受け取るように準備されて、そのサーバとコミュニケートする目的のために与えられるSIPかSIPS URI[4]でDNSルックアップの結果であるかもしれない組み合わせを、移植して、輸送してください。このような関係においては、「分配」であることは、要求か応答にREGISTER要求か再直接の応答、またはRecord-ルートヘッダーフィールドでContactヘッダーフィールドにURIを置くのを含んでいます。 また、ウェブページか名刺にそれを置くことによって、URIを「与えることができます」。 また、サーバがすべての公共のインタフェースのデフォルトSIPポート(TCPの上のTLSのためのTCPとUDP、5061年の5060)に関する要求の聞こうとするのは、RECOMMENDEDです。 典型的な例外は私設のネットワークか複数のサーバインスタンスがいつ同じホストで走っているかということでしょう。 サーバがUDPのために聴くどんなポートとインタフェースに関してはも、それはTCPのためにその同じポートとインタフェースで聴かれなければなりません。 これはメッセージが、それが大き過ぎるならUDPよりむしろTCPが使用させられる必要があるかもしれないからです。 その結果、逆は本当ではありません。 サーバは、ただTCPのためにその同じアドレスとポートの上で聴いているので、特定のアドレスとポートの上のUDPの聞こうとする必要はありません。 もちろん、特定のアドレスとポートの上にサーバがUDPの聞こうとする必要がある他の理由があるかもしれません。

   When the server transport receives a request over any transport, it
   MUST examine the value of the "sent-by" parameter in the top Via
   header field value.  If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.

サーバ輸送がどんな輸送の上にも要求を受け取るとき、それは最高Viaヘッダーフィールド価値における、「送って」パラメタの値を調べなければなりません。 「送って」パラメタのホスト部分がドメイン名を含んでいるか、またはパケットソースアドレスと異なっているIPアドレスを含んでいるなら、サーバは「受け取られていている」パラメタをそのViaヘッダーフィールド価値に加えなければなりません。 このパラメタはパケットが受け取られたソースアドレスを含まなければなりません。 これは応答を送るのにサーバトランスポート層を助けるためのものです、要求が来たソースIPアドレスにそれを送らなければならないので。

   Consider a request received by the server transport which looks like,
   in part:

一部似ているサーバ輸送で受け取られた要求を考えてください:

      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060

INVITE一口: bob@Biloxi.com SIP/2.0Via: SIP/2.0/UDP bobspc.biloxi.com: 5060

   The request is received with a source IP address of 192.0.2.4.
   Before passing the request up, the transport adds a "received"
   parameter, so that the request would look like, in part:

.2がIPが.4に192.0を扱うソースと共に要求を受け取ります。 要求に合格する前に、上がって、輸送は要求が一部似るように、「受け取られていている」パラメタを加えます:

      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4

INVITE一口: bob@Biloxi.com SIP/2.0Via: SIP/2.0/UDP bobspc.biloxi.com:5060; =192.0.2を受け取る、.4

Rosenberg, et. al.          Standards Track                   [Page 145]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[145ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Next, the server transport attempts to match the request to a server
   transaction.  It does so using the matching rules described in
   Section 17.2.3.  If a matching server transaction is found, the
   request is passed to that transaction for processing.  If no match is
   found, the request is passed to the core, which may decide to
   construct a new server transaction for that request.  Note that when
   a UAS core sends a 2xx response to INVITE, the server transaction is
   destroyed.  This means that when the ACK arrives, there will be no
   matching server transaction, and based on this rule, the ACK is
   passed to the UAS core, where it is processed.

次に、サーバ輸送は、サーバトランザクションに要求に合っているのを試みます。 それはそうセクション17.2.3で説明された合っている規則を使用にします。 合っているサーバトランザクションが見つけられるなら、要求は処理のためにそのトランザクションに合格されます。 マッチが全く見つけられないなら、要求はコアに合格されます。(それは、その要求のために新しいサーバトランザクションを構成すると決めるかもしれません)。 UASコアが2xx応答をINVITEに送るとき、サーバトランザクションが破壊されることに注意してください。 これは、ACKが到着するとき、合っているサーバトランザクションが全くないことを意味します、そして、この規則に基づいてACKはUASコアに渡されます。そこでは、それが処理されます。

18.2.2 Sending Responses

18.2.2 送付応答

   The server transport uses the value of the top Via header field in
   order to determine where to send a response.  It MUST follow the
   following process:

サーバ輸送は、応答をどこに送るかを決定するのにトップViaヘッダーフィールドの値を使用します。 それは以下のプロセスに続かなければなりません:

      o  If the "sent-protocol" is a reliable transport protocol such as
         TCP or SCTP, or TLS over those, the response MUST be sent using
         the existing connection to the source of the original request
         that created the transaction, if that connection is still open.
         This requires the server transport to maintain an association
         between server transactions and transport connections.  If that
         connection is no longer open, the server SHOULD open a
         connection to the IP address in the "received" parameter, if
         present, using the port in the "sent-by" value, or the default
         port for that transport, if no port is specified.  If that
         connection attempt fails, the server SHOULD use the procedures
         in [4] for servers in order to determine the IP address and
         port to open the connection and send the response to.

o 「送られたプロトコル」がTCPかSCTPなどの信頼できるトランスポート・プロトコル、またはそれらの上のTLSであるなら、応答に既存の接続をトランザクションを作成したオリジナルの要求の源まで使用させなければなりません、その接続がまだオープンであるなら。 これは、サーバトランザクションと輸送の接続との仲間を維持するためにサーバ輸送を必要とします。 その接続がもうオープンでないなら、サーバSHOULDは「受け取られていている」パラメタのIPアドレスに接続を開きます、存在しているなら、「送って」値におけるポート、またはその輸送のためのデフォルトポートを使用して、ポートが全く指定されないなら。 その接続試みが失敗するなら、接続を開いて、応答を送るIPアドレスとポートを決定して、サーバSHOULDはサーバに[4]で手順を用います。

      o  Otherwise, if the Via header field value contains a "maddr"
         parameter, the response MUST be forwarded to the address listed
         there, using the port indicated in "sent-by", or port 5060 if
         none is present.  If the address is a multicast address, the
         response SHOULD be sent using the TTL indicated in the "ttl"
         parameter, or with a TTL of 1 if that parameter is not present.

o さもなければ、Viaヘッダーフィールド価値が"maddr"パラメタを含んでいて、なにも存在していないなら、応答は、中に「送られた」状態で示されたポートを使用して、そこに記載されたアドレスに送らなければならないか、または5060を移植しなければなりません。 アドレスであり、送られた使用が"ttl"パラメタ、または1のTTLと共に示されたTTLであり、そのパラメタが存在していないなら、マルチキャストアドレス、応答はSHOULDですか?

      o  Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter, using the port indicated
         in the "sent-by" value, or using port 5060 if none is specified
         explicitly.  If this fails, for example, elicits an ICMP "port
         unreachable" response, the procedures of Section 5 of [4]
         SHOULD be used to determine where to send the response.

o さもなければ(頼り無いユニキャスト輸送のために)、最高Viaに「受け取られていている」パラメタがあるなら、「受け取られていている」パラメタのアドレスに応答を送らなければなりません、なにも明らかに指定されないなら「送って」値で示されるか、またはポート5060を使用することでポートを使用して。 例えば、やり損ないはこれであるならICMPの「ポート手の届かない」応答を引き出します、[4] SHOULDのセクション5の手順。応答をどこに送るかを決定するのが使用されてください。

Rosenberg, et. al.          Standards Track                   [Page 146]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[146ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      o  Otherwise, if it is not receiver-tagged, the response MUST be
         sent to the address indicated by the "sent-by" value, using the
         procedures in Section 5 of [4].

o さもなければ、それが受信機でタグ付けをしていないなら、「送って」値によって示されたアドレスに応答を送らなければなりません、[4]のセクション5の手順を用いて。

18.3 Framing

18.3 縁どり

   In the case of message-oriented transports (such as UDP), if the
   message has a Content-Length header field, the message body is
   assumed to contain that many bytes.  If there are additional bytes in
   the transport packet beyond the end of the body, they MUST be
   discarded.  If the transport packet ends before the end of the
   message body, this is considered an error.  If the message is a
   response, it MUST be discarded.  If the message is a request, the
   element SHOULD generate a 400 (Bad Request) response.  If the message
   has no Content-Length header field, the message body is assumed to
   end at the end of the transport packet.

メッセージ指向の輸送(UDPなどの)の場合では、メッセージにContent-長さのヘッダーフィールドがあるなら、メッセージ本体がそんなに多くのバイトを含むと思われます。 追加バイトがボディーの先に輸送パケットにあれば、それらを捨てなければなりません。 輸送パケットがメッセージ本体の先までに終わるなら、これは誤りであると考えられます。 メッセージが応答であるなら、それを捨てなければなりません。 メッセージが要求であるなら、要素SHOULDは400(悪いRequest)応答を生成します。 メッセージにContent-長さのヘッダーフィールドが全くないなら、メッセージ本体が輸送パケットの端で終わると思われます。

   In the case of stream-oriented transports such as TCP, the Content-
   Length header field indicates the size of the body.  The Content-
   Length header field MUST be used with stream oriented transports.

TCPなどのストリーム指向の輸送の場合では、Content長さのヘッダーフィールドはボディーのサイズを示します。 ストリームの指向の輸送と共にContent長さのヘッダーフィールドを使用しなければなりません。

18.4 Error Handling

18.4エラー処理

   Error handling is independent of whether the message was a request or
   response.

エラー処理はメッセージが要求かそれとも応答であったかから独立しています。

   If the transport user asks for a message to be sent over an
   unreliable transport, and the result is an ICMP error, the behavior
   depends on the type of ICMP error.  Host, network, port or protocol
   unreachable errors, or parameter problem errors SHOULD cause the
   transport layer to inform the transport user of a failure in sending.
   Source quench and TTL exceeded ICMP errors SHOULD be ignored.

輸送ユーザが頼り無い輸送の上に送られるべきメッセージを求めて、結果がICMP誤りであるなら、振舞いはICMP誤りのタイプに頼っています。 手の届かない誤りについて接待するか、ネットワークでつなぐか、移植するか、議定書の中で述べてください。さもないと、パラメタ問題誤りSHOULDはトランスポート層に失敗について発信する際に輸送ユーザに知らせさせます。 ソース焼き入れとTTLはICMP誤りSHOULDを超えていました。無視されます。

   If the transport user asks for a request to be sent over a reliable
   transport, and the result is a connection failure, the transport
   layer SHOULD inform the transport user of a failure in sending.

輸送ユーザが信頼できる輸送の上に送られるという要求を求めて、結果が接続失敗であるなら、トランスポート層SHOULDは失敗について発信する際に輸送ユーザに知らせます。

19 Common Message Components

19 一般的なメッセージコンポーネント

   There are certain components of SIP messages that appear in various
   places within SIP messages (and sometimes, outside of them) that
   merit separate discussion.

別々の議論に値するSIPメッセージ(そして、時々それらの外部)の中に様々な場所に現れるSIPメッセージのある成分があります。

Rosenberg, et. al.          Standards Track                   [Page 147]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[147ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

19.1 SIP and SIPS Uniform Resource Indicators

19.1は、一定のリソースインディケータをちびちび飲んで、ちびちび飲みます。

   A SIP or SIPS URI identifies a communications resource.  Like all
   URIs, SIP and SIPS URIs may be placed in web pages, email messages,
   or printed literature.  They contain sufficient information to
   initiate and maintain a communication session with the resource.

SIPかSIPS URIがコミュニケーションリソースを特定します。 すべてのURI、SIP、およびSIPS URIがウェブページに置かれるかもしれないように、メッセージ、または印刷物をメールしてください。 それらはリソースとのコミュニケーションセッションを開始して、維持できるくらいの情報を含んでいます。

   Examples of communications resources include the following:

コミュニケーションリソースに関する例は以下を含んでいます:

      o  a user of an online service

o オンラインサービスのユーザ

      o  an appearance on a multi-line phone

o マルチ系列電話をである外観

      o  a mailbox on a messaging system

o メッセージシステムのメールボックス

      o  a PSTN number at a gateway service

o ゲートウェイサービスにおけるPSTN番号

      o  a group (such as "sales" or "helpdesk") in an organization

o 組織におけるグループ(「販売」か「ヘルプデスク」などの)

   A SIPS URI specifies that the resource be contacted securely.  This
   means, in particular, that TLS is to be used between the UAC and the
   domain that owns the URI.  From there, secure communications are used
   to reach the user, where the specific security mechanism depends on
   the policy of the domain.  Any resource described by a SIP URI can be
   "upgraded" to a SIPS URI by just changing the scheme, if it is
   desired to communicate with that resource securely.

SIPS URIは、リソースがしっかりと連絡されると指定します。 これは、TLSがUACとURIを所有しているドメインの間で使用されることになっていることを特に意味します。 そこから、安全なコミュニケーションはユーザに届くのに使用されます、特定のセキュリティー対策がドメインの方針によるところで。 SIP URIによって説明されたどんなリソースもただ体系を変えることによって、SIPS URIに「アップグレードできます」、そのリソースでしっかりと交信するのが必要であるなら。

19.1.1 SIP and SIPS URI Components

19.1.1 一口と一口URIコンポーネント

   The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].
   They use a form similar to the mailto URL, allowing the specification
   of SIP request-header fields and the SIP message-body.  This makes it
   possible to specify the subject, media type, or urgency of sessions
   initiated by using a URI on a web page or in an email message.  The
   formal syntax for a SIP or SIPS URI is presented in Section 25.  Its
   general form, in the case of a SIP URI, is:

「ちびちび飲んでください」 「以下をちびちび飲みます」 体系はRFC2396[5]でガイドラインに従います。 SIP要求ヘッダーフィールドとSIPメッセージボディーの仕様を許容して、彼らはmailto URLと同様のフォームを使用します。 これで対象を指定するのが可能になるのをメディアがタイプするか、またはセッションの緊急は、ウェブページの上、または、メールメッセージでURIを使用することによって、開始しました。 SIPかSIPS URIに、正式な構文はセクション25に提示されます。 SIP URIの場合では、一般的なフォームは以下の通りです。

      sip:user:password@host:port;uri-parameters?headers

一口:ユーザ: password@host : ポート; uri-パラメタ--ヘッダー

   The format for a SIPS URI is the same, except that the scheme is
   "sips" instead of sip.  These tokens, and some of the tokens in their
   expansions, have the following meanings:

体系が一口の代わりに「一口」であるのを除いて、SIPS URIのための形式は同じです。 これらのトークン、およびそれらの拡張におけるトークンのいくつかには、以下の意味があります:

      user: The identifier of a particular resource at the host being
         addressed.  The term "host" in this context frequently refers
         to a domain.  The "userinfo" of a URI consists of this user
         field, the password field, and the @ sign following them.  The
         userinfo part of a URI is optional and MAY be absent when the

ユーザ: 宛てられるホストの特定のリソースに関する識別子。 「ホスト」という用語は頻繁にこのような関係においてはドメインについて言及します。 URIの"userinfo"はこのユーザ分野、パスワード欄、およびそれらに続く@サインから成ります。 URIのuserinfo部分は、任意であり、いつなしであるかもしれないか。

Rosenberg, et. al.          Standards Track                   [Page 148]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[148ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         destination host does not have a notion of users or when the
         host itself is the resource being identified.  If the @ sign is
         present in a SIP or SIPS URI, the user field MUST NOT be empty.

あて先ホストには、ユーザかそれともいつホスト自身が特定されるリソースであるかに関する考えがありません。 @サインがSIPかSIPS URIに存在しているなら、ユーザ分野は人影がないはずがありません。

         If the host being addressed can process telephone numbers, for
         instance, an Internet telephony gateway, a telephone-
         subscriber field defined in RFC 2806 [9] MAY be used to
         populate the user field.  There are special escaping rules for
         encoding telephone-subscriber fields in SIP and SIPS URIs
         described in Section 19.1.2.

宛てられるホストが電話番号、例えばインターネット電話ゲートウェイを処理できるなら、RFC2806[9]で定義された電話加入者分野は、ユーザ分野に居住するのに使用されるかもしれません。 電話加入者分野をコード化するための特別なエスケープ規則がURIがセクション19.1.2で説明したSIPとSIPSにあります。

      password: A password associated with the user.  While the SIP and
         SIPS URI syntax allows this field to be present, its use is NOT
         RECOMMENDED, because the passing of authentication information
         in clear text (such as URIs) has proven to be a security risk
         in almost every case where it has been used.  For instance,
         transporting a PIN number in this field exposes the PIN.

パスワード: ユーザに関連しているパスワード。 SIPとSIPS URIである間、構文は、この分野が現在であるのを許容して、クリアテキスト(URIなどの)における、認証情報の通過がセキュリティリスクであると判明したので、使用はそれが使用されたほとんどあらゆる場合でNOT RECOMMENDEDです。 例えば、この分野で暗証番号番号を輸送すると、暗証番号は暴露します。

         Note that the password field is just an extension of the user
         portion.  Implementations not wishing to give special
         significance to the password portion of the field MAY simply
         treat "user:password" as a single string.

パスワード欄がただユーザ部分の拡大であることに注意してください。 願望ではなく、分野のパスワード部分に特別な意味を与える実装が単に「ユーザ: パスワード」を一連として扱うかもしれません。

      host: The host providing the SIP resource.  The host part contains
         either a fully-qualified domain name or numeric IPv4 or IPv6
         address.  Using the fully-qualified domain name form is
         RECOMMENDED whenever possible.

以下を接待してください。 SIPリソースを提供するホスト。 ホスト部分は完全修飾ドメイン名か数値IPv4かIPv6アドレスのどちらかを含んでいます。 可能であるときはいつも、完全修飾ドメイン名フォームを使用するのは、RECOMMENDEDです。

      port: The port number where the request is to be sent.

ポート: 送られる要求がことであるポートナンバー。

      URI parameters: Parameters affecting a request constructed from
         the URI.

URIパラメタ: URIから構成された要求に影響するパラメタ。

         URI parameters are added after the hostport component and are
         separated by semi-colons.

URIパラメタは、hostportの部品の後に加えられて、セミコロンによって切り離されます。

         URI parameters take the form:

URIパラメタは形を取ります:

            parameter-name "=" parameter-value

パラメタ名の「=」パラメタ価値

         Even though an arbitrary number of URI parameters may be
         included in a URI, any given parameter-name MUST NOT appear
         more than once.

URIパラメタの特殊活字の数字はURIに含まれるかもしれませんが、どんな与えられたパラメタ名も一度より多く見えてはいけません。

         This extensible mechanism includes the transport, maddr, ttl,
         user, method and lr parameters.

この広げることができるメカニズムは輸送、maddr、ttl、ユーザ、メソッド、およびlrパラメタを含んでいます。

Rosenberg, et. al.          Standards Track                   [Page 149]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[149ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         The transport parameter determines the transport mechanism to
         be used for sending SIP messages, as specified in [4].  SIP can
         use any network transport protocol.  Parameter names are
         defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP
         (RFC 2960 [16]).  For a SIPS URI, the transport parameter MUST
         indicate a reliable transport.

輸送パラメタは、[4]で指定されるように移送機構が送付SIPメッセージに使用されることを決定します。 SIPはどんなネットワークトランスポート・プロトコルも使用できます。 パラメタ名がUDPのために定義される、(RFC768[14])、TCP、(RFC761[15])、およびSCTP、(RFC2960[16])。 SIPS URIに関しては、輸送パラメタは信頼できる輸送を示さなければなりません。

         The maddr parameter indicates the server address to be
         contacted for this user, overriding any address derived from
         the host field.  When an maddr parameter is present, the port
         and transport components of the URI apply to the address
         indicated in the maddr parameter value.  [4] describes the
         proper interpretation of the transport, maddr, and hostport in
         order to obtain the destination address, port, and transport
         for sending a request.

maddrパラメタはこのユーザのために連絡されるためにサーバアドレスを示します、ホスト分野から得られたどんなアドレスもくつがえして。 maddrパラメタが存在しているとき、URIのポートと輸送コンポーネントはmaddrパラメタ価値で示されたアドレスに適用されます。 [4]は、要求を送るための送付先アドレス、ポート、および輸送を入手するために輸送、maddr、およびhostportの適切な解釈について説明します。

         The maddr field has been used as a simple form of loose source
         routing.  It allows a URI to specify a proxy that must be
         traversed en-route to the destination.  Continuing to use the
         maddr parameter this way is strongly discouraged (the
         mechanisms that enable it are deprecated).  Implementations
         should instead use the Route mechanism described in this
         document, establishing a pre-existing route set if necessary
         (see Section 8.1.1.1).  This provides a full URI to describe
         the node to be traversed.

maddr分野は単純形のゆるいソースルーティングとして使用されました。 それで、URIは目的地への途中で横断しなければならないプロキシを指定できます。 このようにmaddrパラメタを使用し続けているのは強くお勧めできないです(それを可能にするメカニズムは推奨しないです)。 セクション8.1を見てください。実装は代わりに本書では説明されたRouteメカニズムを使用するべきです、必要なら、先在のルートセットを設立して(.1 .1)。 これは、横断されるためにノードについて説明するために完全なURIを提供します。

         The ttl parameter determines the time-to-live value of the UDP
         multicast packet and MUST only be used if maddr is a multicast
         address and the transport protocol is UDP.  For example, to
         specify a call to alice@atlanta.com using multicast to
         239.255.255.1 with a ttl of 15, the following URI would be
         used:

ttlパラメタをUDPマルチキャストパケットの生きる時間値を決定して、maddrがマルチキャストアドレスであり、トランスポート・プロトコルがUDPであるなら使用するだけでよいです。 例えば、aを指定するために、15についてaがある.1がttlする.255を239.255への使用マルチキャストに alice@atlanta.com に電話をしてください、そして、以下のURIは使用されるでしょう:

            sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15

一口: alice@atlanta.com;maddr =239.255.255.1; ttl=15

         The set of valid telephone-subscriber strings is a subset of
         valid user strings.  The user URI parameter exists to
         distinguish telephone numbers from user names that happen to
         look like telephone numbers.  If the user string contains a
         telephone number formatted as a telephone-subscriber, the user
         parameter value "phone" SHOULD be present.  Even without this
         parameter, recipients of SIP and SIPS URIs MAY interpret the
         pre-@ part as a telephone number if local restrictions on the
         name space for user name allow it.

有効な電話加入者ストリングのセットは正規ユーザーストリングの部分集合です。 ユーザURIパラメタは、たまたま電話番号に似ているユーザ名と電話番号を区別するために存在しています。 ユーザストリングがフォーマットされた電話番号を含むなら、電話加入者、ユーザパラメタ価値がSHOULDに「電話をする」ように、存在してください。 このパラメタがなくても、ユーザ名のための名前スペースにおけるローカルの制限がそれを許容するなら、SIPとSIPS URIの受取人は電話番号としてプレ@部分を解釈するかもしれません。

         The method of the SIP request constructed from the URI can be
         specified with the method parameter.

メソッドパラメタでURIから構成されたSIP要求のメソッドを指定できます。

Rosenberg, et. al.          Standards Track                   [Page 150]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[150ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

         The lr parameter, when present, indicates that the element
         responsible for this resource implements the routing mechanisms
         specified in this document.  This parameter will be used in the
         URIs proxies place into Record-Route header field values, and
         may appear in the URIs in a pre-existing route set.

存在しているとき、lrパラメタは、このリソースに原因となる要素が、ルーティングが本書では指定されたメカニズムであると実装するのを示します。 このパラメタは、プロキシがRecord-ルートヘッダーフィールド値に置くURIに使用されて、先在のルートセットにURIに現れるかもしれません。

         This parameter is used to achieve backwards compatibility with
         systems implementing the strict-routing mechanisms of RFC 2543
         and the rfc2543bis drafts up to bis-05.  An element preparing
         to send a request based on a URI not containing this parameter
         can assume the receiving element implements strict-routing and
         reformat the message to preserve the information in the
         Request-URI.

このパラメタが厳しいルーティングがRFC2543のメカニズムであると実装するシステムと上がっているrfc2543bis草稿との互換性を後方に獲得するのに使用される、2回、-05 このパラメタを含まないURIに基づく要求を送るのを準備する要素は、受信要素が、厳しいルーティングと再フォーマットがRequest-URIにおける情報を保存するメッセージであると実装すると仮定できます。

         Since the uri-parameter mechanism is extensible, SIP elements
         MUST silently ignore any uri-parameters that they do not
         understand.

uri-パラメタメカニズムが広げることができるので、SIP要素は静かに、彼らが理解していないどんなuri-パラメタも無視しなければなりません。

      Headers: Header fields to be included in a request constructed
         from the URI.

ヘッダー: URIから構成された要求に含まれるべきヘッダーフィールド。

         Headers fields in the SIP request can be specified with the "?"
         mechanism within a URI.  The header names and values are
         encoded in ampersand separated hname = hvalue pairs.  The
         special hname "body" indicates that the associated hvalue is
         the message-body of the SIP request.

URIの中で“?"メカニズムでSIPの分野が要求するヘッダーを指定できます。 ヘッダー名と値はアンパーサンド切り離されたhname=hvalue組でコード化されます。 特別なhname「ボディー」は、関連hvalueがSIP要求のメッセージ本体であることを示します。

   Table 1 summarizes the use of SIP and SIPS URI components based on
   the context in which the URI appears.  The external column describes
   URIs appearing anywhere outside of a SIP message, for instance on a
   web page or business card.  Entries marked "m" are mandatory, those
   marked "o" are optional, and those marked "-" are not allowed.
   Elements processing URIs SHOULD ignore any disallowed components if
   they are present.  The second column indicates the default value of
   an optional element if it is not present.  "--" indicates that the
   element is either not optional, or has no default value.

テーブル1はURIが現れる文脈に基づくSIPとSIPS URIの部品の使用をまとめます。 外部のコラムは例えばウェブページか名刺の上にSIPメッセージの外にどこでも現れるURIについて説明します。 「m」であることが示されるエントリーは義務的です、そして、「o」であるとマークされたものは任意です、そして、「-」であるとマークされたものは許容されていません。 それらが存在しているなら、Elements処理URI SHOULDはどんな禁じられたコンポーネントも無視します。 それが存在していないなら、第2コラムは随意的な要素のデフォルト値を示します。 「--」には、要素が任意でないことを示すか、またはデフォルト値が全くありません。

   URIs in Contact header fields have different restrictions depending
   on the context in which the header field appears.  One set applies to
   messages that establish and maintain dialogs (INVITE and its 200 (OK)
   response).  The other applies to registration and redirection
   messages (REGISTER, its 200 (OK) response, and 3xx class responses to
   any method).

ContactヘッダーフィールドにおけるURIには、ヘッダーフィールドが現れる文脈による異なった制限があります。 1セットは対話が(INVITEとその200(OK)応答)であると確証して、主張するメッセージに適用されます。 もう片方が登録とリダイレクションメッセージ(どんなメソッドへのそのREGISTER、200(OK)応答、および3xxクラス応答も)に適用されます。

Rosenberg, et. al.          Standards Track                   [Page 151]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[151ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

19.1.2 Character Escaping Requirements

19.1.2 キャラクターエスケープ要件

                                                       dialog
                                          reg./redir. Contact/
              default  Req.-URI  To  From  Contact   R-R/Route  external
user          --          o      o    o       o          o         o
password      --          o      o    o       o          o         o
host          --          m      m    m       m          m         m
port          (1)         o      -    -       o          o         o
user-param    ip          o      o    o       o          o         o
method        INVITE      -      -    -       -          -         o
maddr-param   --          o      -    -       o          o         o
ttl-param     1           o      -    -       o          -         o
transp.-param (2)         o      -    -       o          o         o
lr-param      --          o      -    -       -          o         o
other-param   --          o      o    o       o          o         o
headers       --          -      -    -       o          -         o

対話reg/redir。 接触..デフォルト..URI..ルート..外部..ユーザ..パスワード..ホスト..ポート..ユーザ..メソッド..ヘッダー

   (1): The default port value is transport and scheme dependent.  The
   default  is  5060  for  sip: using UDP, TCP, or SCTP.  The default is
   5061 for sip: using TLS over TCP and sips: over TCP.

(1): デフォルトポート価値は、輸送と体系扶養家族です。 デフォルトは一口のための5060です: UDP、TCP、またはSCTPを使用します。 デフォルトは一口のための5061です: TCPの上でTLSを使用して、一口: TCPの上で。

   (2): The default transport is scheme dependent.  For sip:, it is UDP.
   For sips:, it is TCP.

(2): デフォルト輸送は体系扶養家族です。 以下をちびちび飲んでください、そして、それはUDPです。 以下をちびちび飲む、それはTCPです。

   Table 1: Use and default values of URI components for SIP header
   field values, Request-URI and references

テーブル1: SIPヘッダーフィールド値、Request-URI、および参照のためのURIコンポーネントの使用とデフォルト値

   SIP follows the requirements and guidelines of RFC 2396 [5] when
   defining the set of characters that must be escaped in a SIP URI, and
   uses its ""%" HEX HEX" mechanism for escaping.  From RFC 2396 [5]:

SIPは、SIP URIで逃げなければならないキャラクタのセットを定義するとき、RFC2396[5]の要件とガイドラインに従って、逃げるのに「「%」十六進法十六進法」メカニズムを使用します。 RFC2396[5]から:

      The set of characters actually reserved within any given URI
      component is defined by that component.  In general, a character
      is reserved if the semantics of the URI changes if the character
      is replaced with its escaped US-ASCII encoding [5].  Excluded US-
      ASCII characters (RFC 2396 [5]), such as space and control
      characters and characters used as URI delimiters, also MUST be
      escaped.  URIs MUST NOT contain unescaped space and control
      characters.

実際にどんな与えられたURIコンポーネントの中でも予約されたキャラクタのセットはそのコンポーネントによって定義されます。 一般に、URIの意味論が、キャラクタが[5]をコード化する逃げられた米国-ASCIIに取り替えられるかどうかを変えるなら、キャラクタは控え目です。 米国のASCII文字を除く、(スペースや、制御文字やキャラクタなどのRFC2396[5])をURIデリミタとして使用されて、また、逃げなければなりません。 URIは非エスケープしているスペースと制御文字を含んではいけません。

   For each component, the set of valid BNF expansions defines exactly
   which characters may appear unescaped.  All other characters MUST be
   escaped.

各コンポーネントのために、有効なBNF拡張のセットは、どのキャラクタが、非エスケープしているように見えるかもしれないかをまさに定義します。 他のすべてのキャラクタから逃げなければなりません。

   For example, "@" is not in the set of characters in the user
   component, so the user "j@s0n" must have at least the @ sign encoded,
   as in "j%40s0n".

例えば、キャラクタのセットに"@"がユーザコンポーネントにはないので、ユーザ" j@s0n "は少なくとも@サインをコード化させなければなりません、「j%40s0n」のように。

Rosenberg, et. al.          Standards Track                   [Page 152]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[152ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Expanding the hname and hvalue tokens in Section 25 show that all URI
   reserved characters in header field names and values MUST be escaped.

セクション25でhnameとhvalueトークンを広げて、すべてのURIがヘッダーフィールド名でキャラクタを予約して、値から逃げなければならないのを示してください。

   The telephone-subscriber subset of the user component has special
   escaping considerations.  The set of characters not reserved in the
   RFC 2806 [9] description of telephone-subscriber contains a number of
   characters in various syntax elements that need to be escaped when
   used in SIP URIs.  Any characters occurring in a telephone-subscriber
   that do not appear in an expansion of the BNF for the user rule MUST
   be escaped.

ユーザコンポーネントの電話加入者部分集合には、特別なエスケープ問題があります。 電話加入者のRFC2806[9]記述で予約されなかったキャラクタのセットはSIP URIに使用されると逃げられる必要がある様々な構文要素に多くのキャラクタを含んでいます。 電話加入者のユーザ規則に関してBNFの拡張に現れない少しのキャラクタ発生からも逃げなければなりません。

   Note that character escaping is not allowed in the host component of
   a SIP or SIPS URI (the % character is not valid in its expansion).
   This is likely to change in the future as requirements for
   Internationalized Domain Names are finalized.  Current
   implementations MUST NOT attempt to improve robustness by treating
   received escaped characters in the host component as literally
   equivalent to their unescaped counterpart.  The behavior required to
   meet the requirements of IDN may be significantly different.

キャラクタエスケープがSIPかSIPS URIのホストの部品で許されていないことに注意してください(%キャラクタは拡張で有効ではありません)。 Internationalized Domain Namesのための要件が成立させられるとき、これは将来、変化しそうです。 現在の実装は、彼らの非エスケープしている対応者には文字通り同等であるとしてホストコンポーネントで容認された逃げられたキャラクタを扱うことによって丈夫さを改良するのを試みてはいけません。 IDNに関する必要条件を満たすのに必要である振舞いはかなり異なっているかもしれません。

19.1.3 Example SIP and SIPS URIs

19.1.3 例の一口と一口URI

   sip:alice@atlanta.com
   sip:alice:secretword@atlanta.com;transport=tcp
   sips:alice@atlanta.com?subject=project%20x&priority=urgent
   sip:+1-212-555-1212:1234@gateway.com;user=phone
   sips:1212@gateway.com
   sip:alice@192.0.2.4
   sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
   sip:alice;day=tuesday@atlanta.com

一口: tcp alice@atlanta.com 一口:alice: secretword@atlanta.com;transport =一口: 電話 alice@atlanta.com?subject =プロジェクト%20xと優先権=緊急の一口:+1-212-555-1212: 1234@gateway.com;user =一口: 1212@gateway.com 一口: alice@192.0.2.4 一口: atlanta.com; 40atlanta.com一口: alice%alice; =日= tuesday@atlanta.com までのメソッド=REGISTER?

   The last sample URI above has a user field value of
   "alice;day=tuesday".  The escaping rules defined above allow a
   semicolon to appear unescaped in this field.  For the purposes of
   this protocol, the field is opaque.  The structure of that value is
   only useful to the SIP element responsible for the resource.

最後のサンプルURI上には、「aliceに、日がtuesdayと等しいこと」のユーザ分野価値があります。 上で定義されたエスケープ規則は、この分野で非エスケープしているようにセミコロンを見せます。 このプロトコルの目的のために、分野は不透明です。 その価値の構造は単にリソースに原因となるSIP要素の役に立ちます。

19.1.4 URI Comparison

19.1.4 URI比較

   Some operations in this specification require determining whether two
   SIP or SIPS URIs are equivalent.  In this specification, registrars
   need to compare bindings in Contact URIs in REGISTER requests (see
   Section 10.3.).  SIP and SIPS URIs are compared for equality
   according to the following rules:

この仕様に基づくいくつかの操作が、2SIPかSIPS URIが同等であるかどうか決定するのを必要とします。 この仕様では、記録係は、REGISTER要求におけるContact URIにおける結合を比較する必要があります(セクション10.3を見てください)。 以下の規則に従って、SIPとSIPS URIは平等のために比較されます:

      o  A SIP and SIPS URI are never equivalent.

o SIPとSIPS URIは決して同等ではありません。

Rosenberg, et. al.          Standards Track                   [Page 153]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[153ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      o  Comparison of the userinfo of SIP and SIPS URIs is case-
         sensitive.  This includes userinfo containing passwords or
         formatted as telephone-subscribers.  Comparison of all other
         components of the URI is case-insensitive unless explicitly
         defined otherwise.

o SIPとSIPS URIのuserinfoの比較はケース敏感です。 これは電話加入者としてパスワードを含んでいるか、またはフォーマットされたuserinfoを含んでいます。 別の方法で明らかに定義されない場合、URIの他のすべてのコンポーネントの比較は大文字と小文字を区別しないです。

      o  The ordering of parameters and header fields is not significant
         in comparing SIP and SIPS URIs.

o パラメタとヘッダーフィールドの注文はSIPとSIPS URIを比較するのにおいて重要ではありません。

      o  Characters other than those in the "reserved" set (see RFC 2396
         [5]) are equivalent to their ""%" HEX HEX" encoding.

o 「予約」のそれら以外のキャラクターはセットしました。(RFC2396[5])がそれらの「「%」十六進法十六進法」コード化に同等であることを確実にしてください。

      o  An IP address that is the result of a DNS lookup of a host name
         does not match that host name.

o ホスト名のDNSルックアップの結果であるIPアドレスはそのホスト名に合っていません。

      o  For two URIs to be equal, the user, password, host, and port
         components must match.

o 2つのURIが等しいように、ユーザ、パスワード、ホスト、およびポートの部品は合わなければなりません。

         A URI omitting the user component will not match a URI that
         includes one.  A URI omitting the password component will not
         match a URI that includes one.

ユーザコンポーネントを省略するURIは1つを含んでいるURIに合わないでしょう。 パスワードコンポーネントを省略するURIは1つを含んでいるURIに合わないでしょう。

         A URI omitting any component with a default value will not
         match a URI explicitly containing that component with its
         default value.  For instance, a URI omitting the optional port
         component will not match a URI explicitly declaring port 5060.
         The same is true for the transport-parameter, ttl-parameter,
         user-parameter, and method components.

デフォルト値でどんなコンポーネントも省略するURIは明らかにそのコンポーネントを含むURIをデフォルト値に合わせないでしょう。 例えば、任意のポートの部品を省略するURIは5060を移植するように明らかに宣言するURIに合わないでしょう。 輸送パラメタ、ttl-パラメタ、ユーザパラメタ、および方法コンポーネントに、同じくらいは本当です。

            Defining sip:user@host to not be equivalent to
            sip:user@host:5060 is a change from RFC 2543.  When deriving
            addresses from URIs, equivalent addresses are expected from
            equivalent URIs.  The URI sip:user@host:5060 will always
            resolve to port 5060.  The URI sip:user@host may resolve to
            other ports through the DNS SRV mechanisms detailed in [4].

ちびちび飲むために相当していないように一口: user@host を定義します: user@host : 5060はRFC2543からの変化です。 URIからアドレスを得るとき、同等なアドレスは同等なURIから予想されます。 URI一口: user@host :5060は、いつも5060を移植すると決議するでしょう。 URI一口: user@host はDNS SRVを通して[4]で詳細なメカニズムを他のポートに決議するかもしれません。

      o  URI uri-parameter components are compared as follows:

o URI uri-パラメタコンポーネントは以下の通り比較されます:

         -  Any uri-parameter appearing in both URIs must match.

- 両方のURIに現れるどんなuri-パラメタも合わなければなりません。

         -  A user, ttl, or method uri-parameter appearing in only one
            URI never matches, even if it contains the default value.

- 1つのURIだけに現れるユーザ、ttl、または方法uri-パラメタが決して合っていません、デフォルト値を含んでも。

         -  A URI that includes an maddr parameter will not match a URI
            that contains no maddr parameter.

- maddrパラメタを含んでいるURIはmaddrパラメタを全く含まないURIに合わないでしょう。

         -  All other uri-parameters appearing in only one URI are
            ignored when comparing the URIs.

- URIを比較するとき、1つのURIだけに現れる他のすべてのuri-パラメタが無視されます。

Rosenberg, et. al.          Standards Track                   [Page 154]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[154ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      o  URI header components are never ignored.  Any present header
         component MUST be present in both URIs and match for the URIs
         to match.  The matching rules are defined for each header field
         in Section 20.

o URIヘッダーの部品は決して無視されません。 どんな現在のヘッダーの部品も、両方のURIで存在していて、URIが合うように合わなければなりません。 合っている規則はセクション20における各ヘッダーフィールドのために定義されます。

   The URIs within each of the following sets are equivalent:

それぞれの以下のセットの中のURIは同等です:

   sip:%61lice@atlanta.com;transport=TCP
   sip:alice@AtLanTa.CoM;Transport=tcp

一口: %61lice@atlanta.com;transport はTCP一口と等しいです: alice@AtLanTa.CoM;Transport はtcpと等しいです。

   sip:carol@chicago.com
   sip:carol@chicago.com;newparam=5
   sip:carol@chicago.com;security=on

一口: carol@chicago.com 一口: 5が: carol@chicago.com;security =をちびちび飲む carol@chicago.com;newparam =

   sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
   sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com

一口: biloxi.com; 輸送=tcp; 一口と等しい=一口に: ボブの%40biloxi.comはちびちび飲まれます: biloxi.com; 方法=レジスタ; 輸送がtcpと等しいという方法=レジスタ: ボブの%40biloxi.com

   sip:alice@atlanta.com?subject=project%20x&priority=urgent
   sip:alice@atlanta.com?priority=urgent&subject=project%20x

一口: 緊急の、そして、対象の=プロジェクト緊急の一口: alice@atlanta.com?subject =プロジェクト%20xと優先権= alice@atlanta.com?priority =%20x

   The URIs within each of the following sets are not equivalent:

それぞれの以下のセットの中のURIは同等ではありません:

   SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)
   sip:alice@AtLanTa.CoM;Transport=UDP

SIP: ALICE@AtLanTa.CoM;Transport はudp(異なったユーザ名)一口と等しいです: alice@AtLanTa.CoM;Transport はUDPと等しいです。

   sip:bob@biloxi.com                   (can resolve to different ports)
   sip:bob@biloxi.com:5060

一口: bob@biloxi.com (異なるのにポートを決議できる)一口: bob@biloxi.com :5060

   sip:bob@biloxi.com              (can resolve to different transports)
   sip:bob@biloxi.com;transport=udp

一口: bob@biloxi.com (異なるのに輸送を決議できる)一口: bob@biloxi.com;transport はudpと等しいです。

   sip:bob@biloxi.com     (can resolve to different port and transports)
   sip:bob@biloxi.com:6000;transport=tcp

ちびちび飲んでください: bob@biloxi.com (ポートと輸送を異なるのに決議できる)一口: bob@biloxi.com :6000、輸送はtcpと等しいです。

   sip:carol@chicago.com                    (different header component)
   sip:carol@chicago.com?Subject=next%20meeting

一口: 次の carol@chicago.com (異なったヘッダーの部品)一口: carol@chicago.com?Subject =%20meeting

   sip:bob@phone21.boxesbybob.com   (even though that's what
   sip:bob@192.0.2.4                 phone21.boxesbybob.com resolves to)

一口: bob@phone21.boxesbybob.com (それはそうする一口: bob@192.0.2.4 phone21.boxesbybob.comが決議することですが)

   Note that equality is not transitive:

平等が他動でないことに注意してください:

      o  sip:carol@chicago.com and sip:carol@chicago.com;security=on are
         equivalent

o : carol@chicago.com と一口: carol@chicago.com;security =をちびちび飲む、同等です。

      o  sip:carol@chicago.com and sip:carol@chicago.com;security=off
         are equivalent

o 離れて: carol@chicago.com と一口: carol@chicago.com;security =をちびちび飲んでください、同等です。

Rosenberg, et. al.          Standards Track                   [Page 155]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[155ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      o  sip:carol@chicago.com;security=on and
         sip:carol@chicago.com;security=off are not equivalent

o : carol@chicago.com;security =をちびちび飲んで、: carol@chicago.com;security =をちびちび飲む、同等ではありません。

19.1.5 Forming Requests from a URI

19.1.5 URIから要求を形成すること。

   An implementation needs to take care when forming requests directly
   from a URI.  URIs from business cards, web pages, and even from
   sources inside the protocol such as registered contacts may contain
   inappropriate header fields or body parts.

実現は、直接URIから要求を形成するとき、注意する必要があります。 不適当なヘッダーフィールドか身体の部分を含むかもしれません登録されるようなプロトコルでウェブページの、そして、ソースから同等の名刺からのURIが、連絡する。

   An implementation MUST include any provided transport, maddr, ttl, or
   user parameter in the Request-URI of the formed request.  If the URI
   contains a method parameter, its value MUST be used as the method of
   the request.  The method parameter MUST NOT be placed in the
   Request-URI.  Unknown URI parameters MUST be placed in the message's
   Request-URI.

実現は形成要求のRequest-URIにどんな提供された輸送、maddr、ttl、またはユーザパラメタも含まなければなりません。 URIが方法パラメタを含んでいるなら、要求の方法として値を使用しなければなりません。 Request-URIに方法パラメタを置いてはいけません。 メッセージのRequest-URIに未知のURIパラメタを置かなければなりません。

   An implementation SHOULD treat the presence of any headers or body
   parts in the URI as a desire to include them in the message, and
   choose to honor the request on a per-component basis.

実現SHOULDはメッセージにそれらを含んで、要求を光栄に思うのを選ぶ願望としてURIにおける、どんなヘッダーや身体の部分の存在も1コンポーネントあたり1個のベースに扱います。

   An implementation SHOULD NOT honor these obviously dangerous header
   fields: From, Call-ID, CSeq, Via, and Record-Route.

これらの明らかに危険なヘッダーがさばく実現SHOULD NOT名誉: を通して呼び出しID、CSeq、記録的なルートです。

   An implementation SHOULD NOT honor any requested Route header field
   values in order to not be used as an unwitting agent in malicious
   attacks.

どんな要求されたRouteヘッダーフィールドも知らず知らずのエージェントとして悪意ある攻撃に使用されないように評価する実現SHOULD NOT名誉。

   An implementation SHOULD NOT honor requests to include header fields
   that may cause it to falsely advertise its location or capabilities.
   These include: Accept, Accept-Encoding, Accept-Language, Allow,
   Contact (in its dialog usage), Organization, Supported, and User-
   Agent.

実現SHOULD NOT名誉は、ヘッダーフィールドを含むように、それで間違ってその位置か能力の広告を出すかもしれないよう要求します。 これらは: Accept-コード化、Accept-言語、Allow、Contact(対話用法による)、Organization、Supported、およびUserエージェントは受け入れてください。

   An implementation SHOULD verify the accuracy of any requested
   descriptive header fields, including: Content-Disposition, Content-
   Encoding, Content-Language, Content-Length, Content-Type, Date,
   Mime-Version, and Timestamp.

実現SHOULDはどんな要求された描写的であるヘッダーフィールド、包含の精度についても確かめます: 満足している気質の、そして、満足しているコード化、満足している言語、コンテンツの長さ、コンテントタイプ、日付、パントマイムバージョン、およびタイムスタンプ。

   If the request formed from constructing a message from a given URI is
   not a valid SIP request, the URI is invalid.  An implementation MUST
   NOT proceed with transmitting the request.  It should instead pursue
   the course of action due an invalid URI in the context it occurs.

メッセージを構成するので与えられたURIから形成された要求が有効なSIP要求でないなら、URIは無効です。 実現は要求を伝えるのに続いてはいけません。 代わりに行動支払われるべきものを追求するべきである、無効のURI、文脈では、それは起こります。

      The constructed request can be invalid in many ways.  These
      include, but are not limited to, syntax error in header fields,
      invalid combinations of URI parameters, or an incorrect
      description of the message body.

組み立てられた要求は様々な意味で無効である場合があります。 これらが含んでいる、有限でなくて、ヘッダーフィールドにおける構文エラーか、URIパラメタの無効の組み合わせか、メッセージ本体の不正確な記述です。

Rosenberg, et. al.          Standards Track                   [Page 156]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[156ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Sending a request formed from a given URI may require capabilities
   unavailable to the implementation.  The URI might indicate use of an
   unimplemented transport or extension, for example.  An implementation
   SHOULD refuse to send these requests rather than modifying them to
   match their capabilities.  An implementation MUST NOT send a request
   requiring an extension that it does not support.

与えられたURIから形成された要求を送るのは実現を入手できない能力を必要とするかもしれません。 URIは例えば非実行された輸送か拡張子の使用を示すかもしれません。 これらを送るSHOULDが、拒否する実現は、彼らの能力を合わせるようそれらに変更するよりむしろ要求します。 実現で、要求はそれが支持しない拡大を必要としてはいけません。

      For example, such a request can be formed through the presence of
      a Require header parameter or a method URI parameter with an
      unknown or explicitly unsupported value.

例えば、Requireヘッダーパラメタか方法URIパラメタの存在を通して未知の、または、明らかにサポートされない値でそのような要求を形成できます。

19.1.6 Relating SIP URIs and tel URLs

19.1.6 SIP URIとtel URLを関係づけること。

   When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
   entire telephone-subscriber portion of the tel URL, including any
   parameters, is placed into the userinfo part of the SIP or SIPS URI.

aはURLをtelします。いつ、(RFC2806[9])はSIPかSIPS URIに変換されて、どんなパラメタも含むtel URLの全体の電話加入者部分はSIPかSIPS URIのuserinfo部分に置かれるか。

   Thus, tel:+358-555-1234567;postd=pp22 becomes

その結果、tel:+358-555-1234567; postd=pp22はなります。

      sip:+358-555-1234567;postd=pp22@foo.com;user=phone

ちびちび飲んでください: +358-555-1234567、postd= pp22@foo.com;user は電話と等しいです。

   or
      sips:+358-555-1234567;postd=pp22@foo.com;user=phone

または、一口: +358-555-1234567; postdする= pp22@foo.com;user は電話と等しいです。

   not
      sip:+358-555-1234567@foo.com;postd=pp22;user=phone

一口: + 358-555-1234567@foo.com;postd =pp22でない; ユーザ=電話

   or

または

      sips:+358-555-1234567@foo.com;postd=pp22;user=phone

一口: + 358-555-1234567@foo.com;postd =pp22; ユーザ=電話

   In general, equivalent "tel" URLs converted to SIP or SIPS URIs in
   this fashion may not produce equivalent SIP or SIPS URIs.  The
   userinfo of SIP and SIPS URIs are compared as a case-sensitive
   string.  Variance in case-insensitive portions of tel URLs and
   reordering of tel URL parameters does not affect tel URL equivalence,
   but does affect the equivalence of SIP URIs formed from them.

一般に、同等な"tel"URLはSIPに変えなかったかもしれませんか、SIPS URIがこんなやり方で同等なSIPかSIPS URIを生産しないかもしれません。 SIPとSIPS URIのuserinfoは大文字と小文字を区別するストリングとして比較されます。 tel URLの大文字と小文字を区別しない部分とtel URLパラメタに関する再命令における変化は、tel URLの等価性に影響しませんが、それらから形成されたSIP URIの等価性に影響します。

   For example,

例えば

      tel:+358-555-1234567;postd=pp22
      tel:+358-555-1234567;POSTD=PP22

tel: +358-555-1234567; postd=pp22tel:+358-555-1234567; POSTD=PP22

   are equivalent, while

同等である、ゆったり過ごす。

      sip:+358-555-1234567;postd=pp22@foo.com;user=phone
      sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone

一口: +358-555-1234567; 電話postd= pp22@foo.com;user =一口: +358-555-1234567; POSTD= PP22@foo.com;user は電話と等しいです。

Rosenberg, et. al.          Standards Track                   [Page 157]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[157ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   are not.

ありません。

   Likewise,

同様に

      tel:+358-555-1234567;postd=pp22;isub=1411
      tel:+358-555-1234567;isub=1411;postd=pp22

+358-555-1234567; isub=1411; tel: +358-555-1234567; postd=pp22; isub=1411tel:postd=pp22

   are equivalent, while

同等である、ゆったり過ごす。

      sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
      sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone

一口: +358-555-1234567; postd=pp22; isub= 1411@foo.com;user は電話一口と等しいです: +358-555-1234567; isub=1411; postdは pp22@foo.com;user =電話と等しいです。

   are not.

ありません。

   To mitigate this problem, elements constructing telephone-subscriber
   fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold
   any case-insensitive portion of telephone-subscriber to lower case,
   and order the telephone-subscriber parameters lexically by parameter
   name, excepting isdn-subaddress and post-dial, which occur first and
   in that order.  (All components of a tel URL except for future-
   extension parameters are defined to be compared case-insensitive.)

下ろすためにSIPかSIPS URI SHOULD折り目のuserinfo一部分に電話加入者のどんな大文字と小文字を区別しない部分も置くために電話加入者分野を構成する要素は、この問題を緩和するために、パラメタ名で辞書的に電話加入者パラメタをケースに入れて、注文します、isdn-subaddressとポストダイヤルを除いて。ダイヤルは最初にとその注文に現れます。 未来の拡大パラメタ以外の1つのtel URLのすべての成分が比較されるのが定義されます。(大文字と小文字を区別しない、)

   Following this suggestion, both

この提案は続きの両方です。

      tel:+358-555-1234567;postd=pp22
      tel:+358-555-1234567;POSTD=PP22

tel: +358-555-1234567; postd=pp22tel:+358-555-1234567; POSTD=PP22

      become

なってください。

        sip:+358-555-1234567;postd=pp22@foo.com;user=phone

ちびちび飲んでください: +358-555-1234567、postd= pp22@foo.com;user は電話と等しいです。

   and both

そして、両方

        tel:+358-555-1234567;tsp=a.b;phone-context=5
        tel:+358-555-1234567;phone-context=5;tsp=a.b

tel:+358-555-1234567; ティースプーンフルはa.bと等しいです; 電話文脈=5tel:+358-555-1234567; 電話文脈=5; ティースプーンフル=a.b

      become

なってください。

        sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone

一口: +358-555-1234567; 電話文脈=5; ティースプーンフル= a.b@foo.com;user は電話と等しいです。

19.2 Option Tags

19.2 オプションタグ

   Option tags are unique identifiers used to designate new options
   (extensions) in SIP.  These tags are used in Require (Section 20.32),
   Proxy-Require (Section 20.29), Supported (Section 20.37) and
   Unsupported (Section 20.40) header fields.  Note that these options
   appear as parameters in those header fields in an option-tag = token
   form (see Section 25 for the definition of token).

オプションタグはSIPで(拡大)に新しいオプションを指定するのに使用されるユニークな識別子です。 (セクション20.29)が、これらのタグがRequire(セクション20.32)で使用されるのをProxy必要として、Supportedは(セクション20.37)とUnsupported(セクション20.40)ヘッダーフィールドです。 オプションタグ=象徴のそれらのヘッダーフィールドにおけるパラメタが形成されるとき(象徴の定義に関してセクション25を見てください)これらのオプションが現れることに注意してください。

Rosenberg, et. al.          Standards Track                   [Page 158]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[158ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Option tags are defined in standards track RFCs.  This is a change
   from past practice, and is instituted to ensure continuing multi-
   vendor interoperability (see discussion in Section 20.32 and Section
   20.37).  An IANA registry of option tags is used to ensure easy
   reference.

オプションタグは標準化過程RFCsで定義されます。 これは、過去の習慣からの変化であり、マルチ業者相互運用性を続けているのを保証するために設けられます(セクション20.32とセクション20.37で議論を見てください)。 オプションタグのIANA登録は、簡単な参照を確実にするのに使用されます。

19.3 Tags

19.3 タグ

   The "tag" parameter is used in the To and From header fields of SIP
   messages.  It serves as a general mechanism to identify a dialog,
   which is the combination of the Call-ID along with two tags, one from
   each participant in the dialog.  When a UA sends a request outside of
   a dialog, it contains a From tag only, providing "half" of the dialog
   ID.  The dialog is completed from the response(s), each of which
   contributes the second half in the To header field.  The forking of
   SIP requests means that multiple dialogs can be established from a
   single request.  This also explains the need for the two-sided dialog
   identifier; without a contribution from the recipients, the
   originator could not disambiguate the multiple dialogs established
   from a single request.

「タグ」パラメタはSIPメッセージのToとFromヘッダーフィールドに使用されます。 それは対話を特定する一般的機構として機能します。(それは、2個のタグ(対話の各関係者からの1)に伴うCall-IDの組み合わせです)。 UAが対話の外に要求を送るとき、Fromタグだけを含んでいます、対話IDの「半分」を提供して。 対話は応答から完成します。それはToヘッダーフィールドでそれぞれ後半を寄付します。 SIP要求の分岐は、ただ一つの要求から複数の対話を確立できることを意味します。 また、これで、二面の対話識別子の必要性がわかります。 受取人からの貢献がなければ、創始者はただ一つの要求から確立された複数の対話のあいまいさを除くことができませんでした。

   When a tag is generated by a UA for insertion into a request or
   response, it MUST be globally unique and cryptographically random
   with at least 32 bits of randomness.  A property of this selection
   requirement is that a UA will place a different tag into the From
   header of an INVITE than it would place into the To header of the
   response to the same INVITE.  This is needed in order for a UA to
   invite itself to a session, a common case for "hairpinning" of calls
   in PSTN gateways.  Similarly, two INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To tags.

タグがUAによって挿入のために要求か応答に発生するとき、それは暗号で偶発性の少なくとも32ビットで無作為の状態でグローバルにユニークでなければなりません。 この選択要件の特性はUAが同じINVITEへの応答のToヘッダーに置くだろうというのと異なったタグをINVITEのFromヘッダーに置くということです。 UAがセッション(呼び出しのPSTNゲートウェイで"hairpinningする"であるためのよくある例)にそれ自体を招待するのにこれが必要です。 同様に、異なった呼び出しのための2INVITEsには異なったFromタグがあるでしょう、そして、異なった呼び出しのための2つの応答には、異なったToタグがあるでしょう。

   Besides the requirement for global uniqueness, the algorithm for
   generating a tag is implementation-specific.  Tags are helpful in
   fault tolerant systems, where a dialog is to be recovered on an
   alternate server after a failure.  A UAS can select the tag in such a
   way that a backup can recognize a request as part of a dialog on the
   failed server, and therefore determine that it should attempt to
   recover the dialog and any other state associated with it.

グローバルなユニークさのための要件以外に、タグを発生させるためのアルゴリズムは実現特有です。 タグはフォルト・トレラントのシステムで役立っています。そこでは、対話は失敗の後に交互のサーバで回復されることです。 UASはバックアップが、失敗したサーバに要求が対話の一部であると認めて、したがって、それに関連している対話といかなる他の状態も回復するのを試みるべきであると決心できるような方法でタグを選択できます。

20 Header Fields

20 ヘッダー分野

   The general syntax for header fields is covered in Section 7.3.  This
   section lists the full set of header fields along with notes on
   syntax, meaning, and usage.  Throughout this section, we use [HX.Y]
   to refer to Section X.Y of the current HTTP/1.1 specification RFC
   2616 [8].  Examples of each header field are given.

ヘッダーフィールドのための一般的な構文はセクション7.3でカバーされています。 このセクションは構文、意味、および用法に注意に伴うヘッダーフィールドのフルセットを記載します。 このセクション中では、私たちは、現在のHTTP/1.1仕様RFC2616[8]のセクションX.Yについて言及するのに[HX.Y]を使用します。 それぞれのヘッダーフィールドに関する例は出されます。

Rosenberg, et. al.          Standards Track                   [Page 159]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[159ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Information about header fields in relation to methods and proxy
   processing is summarized in Tables 2 and 3.

方法とプロキシ処理と関連したヘッダーフィールドに関する情報はTables2と3にまとめられます。

   The "where" column describes the request and response types in which
   the header field can be used.  Values in this column are:

「どこ」コラムはヘッダーフィールドを使用できる要求と応答タイプについて説明するか。 このコラムの値は以下の通りです。

      R: header field may only appear in requests;

R: ヘッダーフィールドは要求に現れるだけであるかもしれません。

      r: header field may only appear in responses;

r: ヘッダーフィールドは応答に現れるだけであるかもしれません。

      2xx, 4xx, etc.: A numerical value or range indicates response
           codes with which the header field can be used;

2xx、4xxなど: 数値か範囲がヘッダーフィールドを使用できる応答コードを示します。

      c: header field is copied from the request to the response.

c: ヘッダーフィールドは要求から応答までコピーされます。

      An empty entry in the "where" column indicates that the header
           field may be present in all requests and responses.

「どこ」コラムにおける人影のないエントリーは、ヘッダーフィールドがすべての要求と応答で存在しているかもしれないのを示すか。

   The "proxy" column describes the operations a proxy may perform on a
   header field:

「プロキシ」コラムはプロキシがヘッダーフィールドに実行するかもしれない操作について説明します:

      a: A proxy can add or concatenate the header field if not present.

a: プロキシは、ヘッダーフィールドかプレゼントを加えるか、または連結できます。

      m: A proxy can modify an existing header field value.

m: プロキシは既存のヘッダーフィールド値を変更できます。

      d: A proxy can delete a header field value.

d: プロキシはヘッダーフィールド値を削除できます。

      r: A proxy must be able to read the header field, and thus this
           header field cannot be encrypted.

r: プロキシはヘッダーフィールドを読むことができなければなりません、そして、その結果、このヘッダーフィールドはコード化できません。

   The next six columns relate to the presence of a header field in a
   method:

次の6つのコラムが方法によるヘッダーフィールドの存在に関連します:

      c: Conditional; requirements on the header field depend on the
           context of the message.

c: 条件付き。 ヘッダーフィールドに関する要件はメッセージの文脈によります。

      m: The header field is mandatory.

m: ヘッダーフィールドは義務的です。

      m*: The header field SHOULD be sent, but clients/servers need to
           be prepared to receive messages without that header field.

m*: ヘッダーフィールドSHOULDを送って、クライアント/サーバだけが、そのヘッダーフィールドなしでメッセージを受け取るように準備される必要があります。

      o: The header field is optional.

o: ヘッダーフィールドは任意です。

      t: The header field SHOULD be sent, but clients/servers need to be
           prepared to receive messages without that header field.

t: ヘッダーフィールドSHOULDを送って、クライアント/サーバだけが、そのヘッダーフィールドなしでメッセージを受け取るように準備される必要があります。

           If a stream-based protocol (such as TCP) is used as a
           transport, then the header field MUST be sent.

輸送として流れのベースのプロトコル(TCPなどの)を使用するなら、ヘッダーフィールドを送らなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 160]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[160ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      *: The header field is required if the message body is not empty.
           See Sections 20.14, 20.15 and 7.4 for details.

*: メッセージ本体が空でないなら、ヘッダーフィールドが必要です。 詳細に関してセクション20.14、20.15、および7.4を見てください。

      -: The header field is not applicable.

-: ヘッダーフィールドは適切ではありません。

   "Optional" means that an element MAY include the header field in a
   request or response, and a UA MAY ignore the header field if present
   in the request or response (The exception to this rule is the Require
   header field discussed in 20.32).  A "mandatory" header field MUST be
   present in a request, and MUST be understood by the UAS receiving the
   request.  A mandatory response header field MUST be present in the
   response, and the header field MUST be understood by the UAC
   processing the response.  "Not applicable" means that the header
   field MUST NOT be present in a request.  If one is placed in a
   request by mistake, it MUST be ignored by the UAS receiving the
   request.  Similarly, a header field labeled "not applicable" for a
   response means that the UAS MUST NOT place the header field in the
   response, and the UAC MUST ignore the header field in the response.

「任意」は、要素が要求か応答にヘッダーフィールドを含むかもしれないことを意味します、そして、要求か応答で存在しているなら、UA MAYはヘッダーフィールドを無視します(この規則への例外は20.32で議論したRequireヘッダーフィールドです)。 「義務的な」ヘッダーフィールドを要求に存在していなければならなくて、要求を受け取るUASに解釈しなければなりません。 義務的な応答ヘッダーフィールドは応答で存在していなければなりません、そして、応答を処理するUACにヘッダーフィールドを解釈しなければなりません。 ヘッダーがさばく「適切でない」手段は要求に存在しているはずがありません。 1つが間違っている要求に置かれるなら、要求を受け取るUASはそれを無視しなければなりません。 同様に、応答に「適切である」とラベルされなかったヘッダーフィールドは、UAS MUST NOTがヘッダーフィールドを応答に置くことを意味します、そして、UAC MUSTは応答におけるヘッダーフィールドを無視します。

   A UA SHOULD ignore extension header parameters that are not
   understood.

UA SHOULDは理解されていない拡張ヘッダーパラメタを無視します。

   A compact form of some common header field names is also defined for
   use when overall message size is an issue.

また、総合的なメッセージサイズが問題であるときに、いくつかの一般的なヘッダーフィールド名のコンパクト形は使用のために定義されます。

   The Contact, From, and To header fields contain a URI.  If the URI
   contains a comma, question mark or semicolon, 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.

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

20.1 Accept

20.1は受け入れます。

   The Accept header field follows the syntax defined in [H14.1].  The
   semantics are also identical, with the exception that if no Accept
   header field is present, the server SHOULD assume a default value of
   application/sdp.

Acceptヘッダーフィールドは[H14.1]で定義された構文に従います。 また、意味論も同じです、Acceptヘッダーフィールドでないなら存在している例外で、SHOULDがアプリケーション/sdpのデフォルト値であると仮定するサーバ。

   An empty Accept header field means that no formats are acceptable.

空のAcceptヘッダーフィールドは、どんな形式も許容していないことを意味します。

Rosenberg, et. al.          Standards Track                   [Page 161]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[161ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example:

例:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Accept                  R            -   o   -   o   m*  o
      Accept                 2xx           -   -   -   o   m*  o
      Accept                 415           -   c   -   c   c   c
      Accept-Encoding         R            -   o   -   o   o   o
      Accept-Encoding        2xx           -   -   -   o   m*  o
      Accept-Encoding        415           -   c   -   c   c   c
      Accept-Language         R            -   o   -   o   o   o
      Accept-Language        2xx           -   -   -   o   m*  o
      Accept-Language        415           -   c   -   c   c   c
      Alert-Info              R      ar    -   -   -   o   -   -
      Alert-Info             180     ar    -   -   -   o   -   -
      Allow                   R            -   o   -   o   o   o
      Allow                  2xx           -   o   -   m*  m*  o
      Allow                   r            -   o   -   o   o   o
      Allow                  405           -   m   -   m   m   m
      Authentication-Info    2xx           -   o   -   o   o   o
      Authorization           R            o   o   o   o   o   o
      Call-ID                 c       r    m   m   m   m   m   m
      Call-Info                      ar    -   -   -   o   o   o
      Contact                 R            o   -   -   m   o   o
      Contact                1xx           -   -   -   o   -   -
      Contact                2xx           -   -   -   m   o   o
      Contact                3xx      d    -   o   -   o   o   o
      Contact                485           -   o   -   o   o   o
      Content-Disposition                  o   o   -   o   o   o
      Content-Encoding                     o   o   -   o   o   o
      Content-Language                     o   o   -   o   o   o
      Content-Length                 ar    t   t   t   t   t   t
      Content-Type                         *   *   -   *   *   *
      CSeq                    c       r    m   m   m   m   m   m
      Date                            a    o   o   o   o   o   o
      Error-Info           300-699    a    -   o   o   o   o   o
      Expires                              -   -   -   o   -   o
      From                    c       r    m   m   m   m   m   m
      In-Reply-To             R            -   -   -   o   -   -
      Max-Forwards            R      amr   m   m   m   m   m   m
      Min-Expires            423           -   -   -   -   -   m
      MIME-Version                         o   o   -   o   o   o
      Organization                   ar    -   -   -   o   o   o

ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________ Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alert-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * CSeq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o

             Table 2: Summary of header fields, A--O

テーブル2: A--ヘッダーフィールドの概要、O

Rosenberg, et. al.          Standards Track                   [Page 162]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[162ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Header field              where       proxy ACK BYE CAN INV OPT REG
   ___________________________________________________________________
   Priority                    R          ar    -   -   -   o   -   -
   Proxy-Authenticate         407         ar    -   m   -   m   m   m
   Proxy-Authenticate         401         ar    -   o   o   o   o   o
   Proxy-Authorization         R          dr    o   o   -   o   o   o
   Proxy-Require               R          ar    -   o   -   o   o   o
   Record-Route                R          ar    o   o   o   o   o   -
   Record-Route             2xx,18x       mr    -   o   o   o   o   -
   Reply-To                                     -   -   -   o   -   -
   Require                                ar    -   c   -   c   c   c
   Retry-After          404,413,480,486         -   o   o   o   o   o
                            500,503             -   o   o   o   o   o
                            600,603             -   o   o   o   o   o
   Route                       R          adr   c   c   c   c   c   c
   Server                      r                -   o   o   o   o   o
   Subject                     R                -   -   -   o   -   -
   Supported                   R                -   o   o   m*  o   o
   Supported                  2xx               -   o   o   m*  m*  o
   Timestamp                                    o   o   o   o   o   o
   To                        c(1)          r    m   m   m   m   m   m
   Unsupported                420               -   m   -   m   m   m
   User-Agent                                   o   o   o   o   o   o
   Via                         R          amr   m   m   m   m   m   m
   Via                        rc          dr    m   m   m   m   m   m
   Warning                     r                -   o   o   o   o   o
   WWW-Authenticate           401         ar    -   m   -   m   m   m
   WWW-Authenticate           407         ar    -   o   -   o   o   o

ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________________ 優先権..プロキシ..認証..認証..認可..必要..ルート..記録的..ルート..答える..必要;

   Table 3: Summary of header fields, P--Z; (1): copied with possible
   addition of tag

テーブル3: P--ヘッダーフィールドの概要、Z。 (1): タグの可能な添加で、コピーされます。

      Accept: application/sdp;level=1, application/x-private, text/html

受け入れます: アプリケーション/sdp; レベルは1、xアプリケーション/個人的なテキスト/htmlと等しいです。

20.2 Accept-Encoding

20.2、コード化を受け入れます。

   The Accept-Encoding header field is similar to Accept, but restricts
   the content-codings [H3.5] that are acceptable in the response.  See
   [H14.3].  The semantics in SIP are identical to those defined in
   [H14.3].

Acceptをコード化しているヘッダーフィールドは、Acceptと同様ですが、応答で許容できる満足しているコーディング[H3.5]を制限します。 [H14.3]を見てください。 SIPの意味論は[H14.3]で定義されたものと同じです。

   An empty Accept-Encoding header field is permissible.  It is
   equivalent to Accept-Encoding: identity, that is, only the identity
   encoding, meaning no encoding, is permissible.

空のAcceptをコード化しているヘッダーフィールドは許されています。 それはAccept-コード化に同等です: アイデンティティ(すなわち、コード化することを意味しないで、コード化されるアイデンティティだけ)は許されています。

   If no Accept-Encoding header field is present, the server SHOULD
   assume a default value of identity.

どんなAcceptをコード化しているヘッダーフィールドも存在していないなら、サーバSHOULDはアイデンティティのデフォルト値を仮定します。

Rosenberg, et. al.          Standards Track                   [Page 163]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[163ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   This differs slightly from the HTTP definition, which indicates that
   when not present, any encoding can be used, but the identity encoding
   is preferred.

これはHTTP定義と若干異なります。(どんなプレゼント、どんなコード化も使用できませんがも、アイデンティティコード化が好まれるとき、それは、それを示します)。

   Example:

例:

      Accept-Encoding: gzip

コード化を受け入れます: gzip

20.3 Accept-Language

20.3、言語を受け入れます。

   The Accept-Language header field is used in requests to indicate the
   preferred languages for reason phrases, session descriptions, or
   status responses carried as message bodies in the response.  If no
   Accept-Language header field is present, the server SHOULD assume all
   languages are acceptable to the client.

Accept-言語ヘッダーフィールドはメッセージ本体として応答で運ばれた理由句、セッション記述、または状態応答のために都合のよい言語を示すという要求で使用されます。 どんなAccept-言語ヘッダーフィールドも存在していないなら、サーバSHOULDは、クライアントにとって、すべての言語が許容できると仮定します。

   The Accept-Language header field follows the syntax defined in
   [H14.4].  The rules for ordering the languages based on the "q"
   parameter apply to SIP as well.

Accept-言語ヘッダーフィールドは[H14.4]で定義された構文に従います。 言語を「q」パラメタに基礎づけるよう命令するための規則はまた、SIPに適用されます。

   Example:

例:

      Accept-Language: da, en-gb;q=0.8, en;q=0.7

言語を受け入れます: da、アン-gb; q=0.8、アン; q=0.7

20.4 Alert-Info

20.4 注意深いインフォメーション

   When present in an INVITE request, the Alert-Info header field
   specifies an alternative ring tone to the UAS.  When present in a 180
   (Ringing) response, the Alert-Info header field specifies an
   alternative ringback tone to the UAC.  A typical usage is for a proxy
   to insert this header field to provide a distinctive ring feature.

INVITE要求に存在しているとき、Alert-インフォメーションヘッダーフィールドは代替の着信音をUASに指定します。 180(鳴る)応答で存在しているとき、Alert-インフォメーションヘッダーフィールドは代替のringbackトーンをUACに指定します。 典型的な用法はプロキシが特有のリングの特徴を提供するためにこのヘッダーフィールドを挿入することです。

   The Alert-Info header field can introduce security risks.  These
   risks and the ways to handle them are discussed in Section 20.9,
   which discusses the Call-Info header field since the risks are
   identical.

Alert-インフォメーションヘッダーフィールドはセキュリティ危険を導入できます。 セクション20.9でこれらの危険とそれらを扱う方法について議論します。(リスクが同じであるので、それは、Call-インフォメーションヘッダーフィールドについて議論します)。

   In addition, a user SHOULD be able to disable this feature
   selectively.

追加、ユーザSHOULD、選択的にこの特徴を無効にすることができてください。

      This helps prevent disruptions that could result from the use of
      this header field by untrusted elements.

これは、信頼されていない要素に従ったこのヘッダーフィールドの使用から生じることができた分裂を防ぐのを助けます。

   Example:

例:

      Alert-Info: <http://www.example.com/sounds/moo.wav>

注意深いインフォメーション: <http://www.example.com/音/moo.wav>。

Rosenberg, et. al.          Standards Track                   [Page 164]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[164ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

20.5 Allow

20.5は許容します。

   The Allow header field lists the set of methods supported by the UA
   generating the message.

Allowヘッダーフィールドはメッセージを生成するUAによってサポートされたメソッドのセットを記載します。

   All methods, including ACK and CANCEL, understood by the UA MUST be
   included in the list of methods in the Allow header field, when
   present.  The absence of an Allow header field MUST NOT be
   interpreted to mean that the UA sending the message supports no
   methods.   Rather, it implies that the UA is not providing any
   information on what methods it supports.

メソッドのリストにAllowヘッダーフィールドでACKとキャンセルを含むメソッドがUaで理解していたすべてを含まなければなりません、存在しているとき。 メッセージを送るUAがメソッドを全くサポートしないことを意味するためにAllowヘッダーフィールドの欠如を解釈してはいけません。 むしろ、それは、UAがそれがどんなメソッドをサポートするかの少しの情報も提供していないのを含意します。

   Supplying an Allow header field in responses to methods other than
   OPTIONS reduces the number of messages needed.

応答におけるAllowヘッダーフィールドをOPTIONS以外のメソッドに供給すると、必要であるメッセージの数は減少します。

   Example:

例:

      Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

許容します: 招待、ACK、オプションが中止される、さようなら

20.6 Authentication-Info

20.6 認証インフォメーション

   The Authentication-Info header field provides for mutual
   authentication with HTTP Digest.  A UAS MAY include this header field
   in a 2xx response to a request that was successfully authenticated
   using digest based on the Authorization header field.

Authentication-インフォメーションヘッダーフィールドはHTTP Digestとの互いの認証に備えます。 UAS MAYはAuthorizationヘッダーフィールドに基づくダイジェストを使用することで首尾よく認証された要求への2xx応答にこのヘッダーフィールドを含んでいます。

   Syntax and semantics follow those specified in RFC 2617 [17].

構文と意味論はRFC2617[17]で指定されたものに続きます。

   Example:

例:

      Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

認証インフォメーション: nextnonceは"47364c23432d2e131a5fb210812c"と等しいです。

20.7 Authorization

20.7 承認

   The Authorization header field contains authentication credentials of
   a UA.  Section 22.2 overviews the use of the Authorization header
   field, and Section 22.4 describes the syntax and semantics when used
   with HTTP authentication.

AuthorizationヘッダーフィールドはUAの認証資格証明書を含んでいます。 セクション22.2 概要、Authorizationヘッダーフィールドの使用、HTTP認証と共に使用されると、セクション22.4は構文と意味論について説明します。

   This header field, along with Proxy-Authorization, breaks the general
   rules about multiple header field values.  Although not a comma-
   separated list, this header field name may be present multiple times,
   and MUST NOT be combined into a single header line using the usual
   rules described in Section 7.3.

このヘッダーフィールドはProxy-承認と共に複数のヘッダーフィールド値に関する総則を破ります。 どんなコンマもリストを切り離しませんでしたが、このヘッダーフィールド名は、プレゼント複数の回であるかもしれなく、セクション7.3で説明された普通の規則を使用することでただ一つのヘッダー系列に結合されてはいけません。

Rosenberg, et. al.          Standards Track                   [Page 165]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[165ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   In the example below, there are no quotes around the Digest
   parameter:

以下の例には、Digestパラメタの周りに引用文が全くありません:

      Authorization: Digest username="Alice", realm="atlanta.com",
       nonce="84a4cc6f3082121f32b42a2187831a9e",
       response="7587245234b3434cc3412213e5f113a5432"

承認: ユーザ名=「アリス」、分野="atlanta.com"一回だけ="84a4cc6f3082121f32b42a2187831a9e"を読みこなしてください、そして、応答は"7587245234b3434cc3412213e5f113a5432"と等しいです。

20.8 Call-ID

20.8 呼び出しID

   The Call-ID header field uniquely identifies a particular invitation
   or all registrations of a particular client.  A single multimedia
   conference can give rise to several calls with different Call-IDs,
   for example, if a user invites a single individual several times to
   the same (long-running) conference.  Call-IDs are case-sensitive and
   are simply compared byte-by-byte.

Call-IDヘッダーフィールドは唯一特定の招待状か特定のクライアントのすべての登録証明書を特定します。 例えば、ユーザが何度か同じ(長い実行すること)の会議に単独の個人を招待するなら、ただ一つのマルチメディア会議は異なったCall-IDとのいくつかの呼び出しをもたらすことができます。 呼び出しIDは、大文字と小文字を区別していて、バイトごとに単に比較されます。

   The compact form of the Call-ID header field is i.

Call-IDヘッダーフィールドのコンパクト形はiです。

   Examples:

例:

      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
      i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

呼び出しID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

20.9 Call-Info

20.9 呼び出しインフォメーション

   The Call-Info header field provides additional information about the
   caller or callee, depending on whether it is found in a request or
   response.  The purpose of the URI is described by the "purpose"
   parameter.  The "icon" parameter designates an image suitable as an
   iconic representation of the caller or callee.  The "info" parameter
   describes the caller or callee in general, for example, through a web
   page.  The "card" parameter provides a business card, for example, in
   vCard [36] or LDIF [37] formats.  Additional tokens can be registered
   using IANA and the procedures in Section 27.

Call-インフォメーションヘッダーフィールドは訪問者か訪問される人に関する追加情報を提供します、それが要求か応答で見つけられるかどうかによって。 URIの目的は「目的」パラメタによって説明されます。 「アイコン」パラメタは訪問者か訪問される人の映像的表象として適当なイメージを指定します。 例えば、「インフォメーション」パラメタはウェブページを通して一般に、訪問者か訪問される人について説明します。 例えば、「カード」パラメタはvCard[36]かLDIF[37]形式に名刺を供給します。 セクション27のIANAと手順を用いることで追加トークンを登録できます。

   Use of the Call-Info header field can pose a security risk.  If a
   callee fetches the URIs provided by a malicious caller, the callee
   may be at risk for displaying inappropriate or offensive content,
   dangerous or illegal content, and so on.  Therefore, it is
   RECOMMENDED that a UA only render the information in the Call-Info
   header field if it can verify the authenticity of the element that
   originated the header field and trusts that element.  This need not
   be the peer UA; a proxy can insert this header field into requests.

Call-インフォメーションヘッダーフィールドの使用はセキュリティリスクを引き起こすことができます。 訪問される人が悪意がある訪問者によって提供されたURIをとって来るなら、訪問される人は、危険な状態に不適当であるか不快な内容、危険であるか不法な内容などを表示するものであるかもしれません。 したがって、その要素にヘッダーフィールドと受託を溯源した要素の信憑性について確かめることができる場合にだけUAがCall-インフォメーションヘッダーフィールドに情報を表すのは、RECOMMENDEDです。 これは同輩UAである必要はありません。 プロキシはこのヘッダーフィールドを要求に挿入できます。

   Example:

例:

   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
     <http://www.example.com/alice/> ;purpose=info

呼び出しインフォメーション: <http://wwww.example.com/alice/photo.jpg>; 目的はアイコン、<http://www.example.com/alice/>と等しいです; 目的はインフォメーションと等しいです。

Rosenberg, et. al.          Standards Track                   [Page 166]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[166ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

20.10 Contact

20.10 接触

   A Contact header field value provides a URI whose meaning depends on
   the type of request or response it is in.

Contactヘッダーフィールド価値は意味をそれがある要求か応答のタイプに頼るURIを提供します。

   A Contact header field value can contain a display name, a URI with
   URI parameters, and header parameters.

Contactヘッダーフィールド価値はディスプレイ名、URIパラメタがあるURI、およびヘッダーパラメタを含むことができます。

   This document defines the Contact parameters "q" and "expires".
   These parameters are only used when the Contact is present in a
   REGISTER request or response, or in a 3xx response.  Additional
   parameters may be defined in other specifications.

このドキュメントは、Contactパラメタ「q」を定義して、「期限が切れます」。 ContactがREGISTER要求か応答、または3xx応答で存在しているときだけ、これらのパラメタは使用されます。 追加パラメタは他の仕様に基づき定義されるかもしれません。

   When the header field value contains a display name, the URI
   including all URI parameters is enclosed in "<" and ">".  If no "<"
   and ">" are present, all parameters after the URI are header
   parameters, not URI parameters.  The display name can be tokens, or a
   quoted string, if a larger character set is desired.

ヘッダーフィールド値がディスプレイ名を含むとき、すべてのURIパラメタを含むURIは"<"と">"に同封されます。 "<"とどんな">"も存在していないなら、URIの後のすべてのパラメタがURIパラメタではなく、ヘッダーパラメタです。 より大きい文字集合が望まれているなら、ディスプレイ名は、トークン、または引用文字列であるかもしれません。

   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, semicolon, or question
   mark.  There may or may not be LWS between the display-name and the
   "<".

「ディスプレイ名」が空であっても、「addr-仕様」がコンマ、セミコロン、または疑問符を含んでいるなら、「名前-addr」フォームを使用しなければなりません。 ディスプレイ名と"<"の間には、LWSがあるかもしれません。

   These rules for parsing a display name, URI and URI parameters, and
   header parameters also apply for the header fields To and From.

また、ディスプレイ名を分析するためのこれらの規則、URI、URIパラメタ、およびヘッダーパラメタはヘッダーフィールドのToとFromに申し込みます。

      The Contact header field has a role similar to the Location header
      field in HTTP.  However, the HTTP header field only allows one
      address, unquoted.  Since URIs can contain commas and semicolons
      as reserved characters, they can be mistaken for header or
      parameter delimiters, respectively.

Contactヘッダーフィールドには、HTTPにおけるLocationヘッダーフィールドと同様の役割があります。 しかしながら、引用を終わられて、HTTPヘッダ分野は1つのアドレスしか許容しません。 URIが控え目なキャラクタとしてコンマとセミコロンを含むことができるので、それぞれヘッダーかパラメタデリミタに彼らを間違えることができます。

   The compact form of the Contact header field is m (for "moved").

Contactヘッダーフィールドのコンパクト形はm(「移行」のための)です。

   Examples:

例:

      Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
         ;q=0.7; expires=3600,
         "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
      m: <sips:bob@192.0.2.4>;expires=60

接触: 「ワトソンさん」<一口: watson@worcester.bell-telephone.com 、gt;、; q=0.7。 「ワトソンさん」<mailto: =3600、 watson@bell-telephone.com を吐き出す、gt;、; q=0.1m: <一口: bob@192.0.2.4 、gt;、;、=60を吐き出します。

Rosenberg, et. al.          Standards Track                   [Page 167]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[167ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

20.11 Content-Disposition

20.11 満足している気質

   The Content-Disposition header field describes how the message body
   or, for multipart messages, a message body part is to be interpreted
   by the UAC or UAS.  This SIP header field extends the MIME Content-
   Type (RFC 2183 [18]).

Content-気質ヘッダーフィールドはUACかUASによって解釈されるメッセージ本体か複合メッセージのためのメッセージ身体の部分がことである方法を説明します。 このSIPヘッダーフィールドはContentがタイプするMIMEを広げています。(RFC2183[18])。

   Several new "disposition-types" of the Content-Disposition header are
   defined by SIP.  The value "session" indicates that the body part
   describes a session, for either calls or early (pre-call) media.  The
   value "render" indicates that the body part should be displayed or
   otherwise rendered to the user.  Note that the value "render" is used
   rather than "inline" to avoid the connotation that the MIME body is
   displayed as a part of the rendering of the entire message (since the
   MIME bodies of SIP messages oftentimes are not displayed to users).
   For backward-compatibility, if the Content-Disposition header field
   is missing, the server SHOULD assume bodies of Content-Type
   application/sdp are the disposition "session", while other content
   types are "render".

Content-気質ヘッダーの数個の新しい「気質タイプ」がSIPによって定義されます。 値の「セッション」は、身体の部分が呼び出しか(あらかじめ呼びます)早めのメディアのどちらかのためにセッションについて説明するのを示します。 「レンダリング値の」は、身体の部分を表示するべきであるか、または別の方法でユーザに提供するべきであるのを示します。 値の「レンダリング」がMIME本体が含蓄ですが、避ける「インライン」よりむしろ全体のメッセージのレンダリングの一部として表示していた状態で使用されることに注意してください(しばしばSIPメッセージのMIME本体をユーザに表示するというわけではないので)。 後方の互換性のために、Content-気質ヘッダーフィールドがなくなるなら、サーバSHOULDは、コンテントタイプアプリケーション/sdpのボディーが気質「セッション」であると仮定します、他のcontent typeは「レンダリング」ですが。

   The disposition type "icon" indicates that the body part contains an
   image suitable as an iconic representation of the caller or callee
   that could be rendered informationally by a user agent when a message
   has been received, or persistently while a dialog takes place.  The
   value "alert" indicates that the body part contains information, such
   as an audio clip, that should be rendered by the user agent in an
   attempt to alert the user to the receipt of a request, generally a
   request that initiates a dialog; this alerting body could for example
   be rendered as a ring tone for a phone call after a 180 Ringing
   provisional response has been sent.

気質タイプ「アイコン」は、メッセージを受け取ったときユーザエージェントが情報にすることができた訪問者か訪問される人について身体の部分が映像的表象として適当なイメージを含むのを示すか、対話は行われますが、または持続して示します。 値の「警戒」は、身体の部分がユーザエージェントによって要求の領収書にユーザの注意を喚起する試みように表されるべきであるオーディオクリップの情報を含むのを示します、一般に対話を開始する要求。 例えば、180のRingingの暫定的な応答の後の電話のための着信音を送ったとき、この警告ボディーをレンダリングできました。

   Any MIME body with a "disposition-type" that renders content to the
   user should only be processed when a message has been properly
   authenticated.

メッセージが適切に認証されたときだけ、内容をユーザに提供する「気質タイプ」があるどんなMIME本体も処理されるべきです。

   The handling parameter, handling-param, describes how the UAS should
   react if it receives a message body whose content type or disposition
   type it does not understand.  The parameter has defined values of
   "optional" and "required".  If the handling parameter is missing, the
   value "required" SHOULD be assumed.  The handling parameter is
   described in RFC 3204 [19].

取り扱いパラメタ(取り扱い-param)はcontent typeか気質タイプを理解していないメッセージ本体を受けるならUASがどう反応するはずであるかを説明します。 パラメタは「任意で」「必要」の値を定義しました。 値が、取り扱いパラメタがなくなるのを「必要だった」というSHOULDであるなら、想定されてください。 取り扱いパラメタはRFC3204[19]で説明されます。

   If this header field is missing, the MIME type determines the default
   content disposition.  If there is none, "render" is assumed.

このヘッダーフィールドがなくなるなら、MIMEの種類はデフォルト内容気質を決定します。 なにもなければ、「レンダリング」は想定されます。

   Example:

例:

      Content-Disposition: session

満足している気質: セッション

Rosenberg, et. al.          Standards Track                   [Page 168]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[168ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

20.12 Content-Encoding

20.12 内容コード化

   The Content-Encoding header field is used as a modifier to the
   "media-type".  When present, its value indicates what additional
   content codings have been applied to the entity-body, and thus what
   decoding mechanisms MUST be applied in order to obtain the media-type
   referenced by the Content-Type header field.  Content-Encoding is
   primarily used to allow a body to be compressed without losing the
   identity of its underlying media type.

Contentをコード化しているヘッダーフィールドは修飾語として「メディアタイプ」に使用されます。 存在しているとき、値はどんな追加満足しているコーディングが実体本体に適用されるか、そして、その結果、コンテントタイプヘッダーフィールドによって参照をつけられるメディアタイプを得るためにどんな解読メカニズムを適用しなければならないかを示します。 内容コード化は、ボディーが基本的なメディアタイプのアイデンティティを失わないで圧縮されるのを許容するのに主として使用されます。

   If multiple encodings have been applied to an entity-body, the
   content codings MUST be listed in the order in which they were
   applied.

複数のencodingsが実体本体に当てられたなら、それらが適用されたオーダーに満足しているコーディングを記載しなければなりません。

   All content-coding values are case-insensitive.  IANA acts as a
   registry for content-coding value tokens.  See [H3.5] for a
   definition of the syntax for content-coding.

すべての内容をコード化する値が大文字と小文字を区別しないです。 IANAは内容をコード化する値のトークンのための登録として機能します。 内容でコード化するための構文の定義に関して[H3.5]を見てください。

   Clients MAY apply content encodings to the body in requests.  A
   server MAY apply content encodings to the bodies in responses.  The
   server MUST only use encodings listed in the Accept-Encoding header
   field in the request.

クライアントは内容encodingsを要求におけるボディーに当てるかもしれません。 サーバは応答で内容encodingsをボディーに当てるかもしれません。 サーバは要求でAcceptをコード化しているヘッダーフィールドで記載されたencodingsを使用するだけでよいです。

   The compact form of the Content-Encoding header field is e.
   Examples:

Contentをコード化しているヘッダーフィールドのコンパクト形はeです。 例:

      Content-Encoding: gzip
      e: tar

内容をコード化しています: gzip e: タール

20.13 Content-Language

20.13 満足している言語

   See [H14.12]. Example:

[H14.12]を見てください。 例:

      Content-Language: fr

満足している言語: fr

20.14 Content-Length

20.14 コンテンツの長さ

   The Content-Length header field indicates the size of the message-
   body, in decimal number of octets, sent to the recipient.
   Applications SHOULD use this field to indicate the size of the
   message-body to be transferred, regardless of the media type of the
   entity.  If a stream-based protocol (such as TCP) is used as
   transport, the header field MUST be used.

Content-長さのヘッダーフィールドは、八重奏の10進数における、メッセージ本体のサイズが受取人に発信したのを示します。 アプリケーションSHOULDは移すためにメッセージ本体のサイズを示すのにこの分野を使用します、実体のメディアタイプにかかわらず。 ストリームベースのプロトコル(TCPなどの)が輸送として使用されるなら、ヘッダーフィールドを使用しなければなりません。

   The size of the message-body does not include the CRLF separating
   header fields and body.  Any Content-Length greater than or equal to
   zero is a valid value.  If no body is present in a message, then the
   Content-Length header field value MUST be set to zero.

メッセージ本体のサイズはCRLF分離ヘッダーフィールドとボディーを含んでいません。 どんなゼロ以上のContent-長さも有効値です。 どんなボディーもメッセージに存在していないなら、Content-長さのヘッダーフィールド価値をゼロに設定しなければなりません。

Rosenberg, et. al.          Standards Track                   [Page 169]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[169ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      The ability to omit Content-Length simplifies the creation of
      cgi-like scripts that dynamically generate responses.

Content-長さを省略する能力はダイナミックに応答を生成する管路気中送電のようなスクリプトの作成を簡素化します。

   The compact form of the header field is l.

ヘッダーフィールドのコンパクト形はlです。

   Examples:

例:

      Content-Length: 349
      l: 173

コンテンツの長さ: 349l: 173

20.15 Content-Type

20.15 コンテントタイプ

   The Content-Type header field indicates the media type of the
   message-body sent to the recipient.  The "media-type" element is
   defined in [H3.7].  The Content-Type header field MUST be present if
   the body is not empty.  If the body is empty, and a Content-Type
   header field is present, it indicates that the body of the specific
   type has zero length (for example, an empty audio file).

コンテントタイプヘッダーフィールドは、メッセージ本体のメディアタイプが受取人に発信したのを示します。 「メディアタイプ」要素は[H3.7]で定義されます。 ボディーが空でないなら、コンテントタイプヘッダーフィールドは存在していなければなりません。 ボディーが空であり、コンテントタイプヘッダーフィールドが存在しているなら、それは、特定のタイプのボディーにはゼロ・レングス(例えば、空のオーディオファイル)があるのを示します。

   The compact form of the header field is c.

ヘッダーフィールドのコンパクト形はcです。

   Examples:

例:

      Content-Type: application/sdp
      c: text/html; charset=ISO-8859-4

コンテントタイプ: アプリケーション/sdp c: テキスト/html。 charset=ISO-8859-4

20.16 CSeq

20.16 CSeq

   A CSeq header field in a request contains a single decimal sequence
   number and the request method.  The sequence number MUST be
   expressible as a 32-bit unsigned integer.  The method part of CSeq is
   case-sensitive.  The CSeq header field serves to order transactions
   within a dialog, to provide a means to uniquely identify
   transactions, and to differentiate between new requests and request
   retransmissions.  Two CSeq header fields are considered equal if the
   sequence number and the request method are identical.  Example:

要求におけるCSeqヘッダーフィールドはただ一つの10進一連番号と要求メソッドを含んでいます。 一連番号は32ビットの符号のない整数として表現できるに違いありません。 CSeqのメソッド部分は大文字と小文字を区別しています。 CSeqヘッダーフィールドは対話の中でトランザクションを命令して、唯一トランザクションを特定する手段を提供して、新しい要求を区別して、「再-トランスミッション」を要求するのに役立ちます。 一連番号と要求メソッドが同じであるなら、2つのCSeqヘッダーフィールドが等しいと考えられます。 例:

      CSeq: 4711 INVITE

CSeq: 4711年の招待

20.17 Date

20.17 日付

   The Date header field contains the date and time.  Unlike HTTP/1.1,
   SIP only supports the most recent RFC 1123 [20] format for dates.  As
   in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while
   RFC 1123 allows any time zone.  An RFC 1123 date is case-sensitive.

Dateヘッダーフィールドは日時を含んでいます。 HTTP/1.1と異なって、SIPは、日付に最新のRFC1123が[20]形式であるとサポートするだけです。 [H3.3]のように、SIPは「グリニッジ標準時にSIP-日付から」時間帯を制限しますが、RFC1123はどんな時間帯も許容します。 1123年のRFC期日は大文字と小文字を区別しています。

   The Date header field reflects the time when the request or response
   is first sent.

Dateヘッダーフィールドは要求か応答が最初に送られる時を反映します。

Rosenberg, et. al.          Standards Track                   [Page 170]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[170ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      The Date header field can be used by simple end systems without a
      battery-backed clock to acquire a notion of current time.
      However, in its GMT form, it requires clients to know their offset
      from GMT.

Dateヘッダーフィールドは簡単なエンドシステムによってバッテリーで支持された時計なしで使用されて、現在の時間の概念を帯びることができます。 それはグリニッジ標準時です。しかしながら中、形成してください、そして、グリニッジ標準時から彼らのオフセットを知るのがクライアントを必要とします。

   Example:

例:

      Date: Sat, 13 Nov 2010 23:29:00 GMT

日付: グリニッジ標準時2010年11月13日土曜日23時29分0秒

20.18 Error-Info

20.18 誤りインフォメーション

   The Error-Info header field provides a pointer to additional
   information about the error status response.

Error-インフォメーションヘッダーフィールドはエラー状況応答に関する追加情報に指針を提供します。

      SIP UACs have user interface capabilities ranging from pop-up
      windows and audio on PC softclients to audio-only on "black"
      phones or endpoints connected via gateways.  Rather than forcing a
      server generating an error to choose between sending an error
      status code with a detailed reason phrase and playing an audio
      recording, the Error-Info header field allows both to be sent.
      The UAC then has the choice of which error indicator to render to
      the caller.

SIP UACsは「黒い」電話かゲートウェイを通してつなげられた終点にPC softclientsの上のポップアップウィンドウとオーディオからオーディオだけまで及ぶユーザーインタフェース能力を持っています。 詳細な理由句がある誤りステータスコードを送って、録音をプレーするときエラーを起こすサーバを選ばせるよりむしろ、Error-インフォメーションヘッダーフィールドは、両方が送られるのを許容します。 そして、UACには、選択がどのエラー・インジケータを訪問者に表すかをあります。

   A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if
   it were a Contact in a redirect and generate a new INVITE, resulting
   in a recorded announcement session being established.  A non-SIP URI
   MAY be rendered to the user.

A UAC MAYがSIPを扱うか、Error-インフォメーションヘッダーフィールドにおけるSIPS URIはまるでそれがaのContactであるかのように新しいINVITEを向け直して、生成します、確立される記録された発表セッションのときになって。 非SIP URI MAY、ユーザに提供してください。

   Examples:

例:

      SIP/2.0 404 The number you have dialed is not in service
      Error-Info: <sip:not-in-service-recording@atlanta.com>

SIP/2.0 404、あなたがダイヤルした番号は使用中のError-インフォメーションではありません: <一口: not-in-service-recording@atlanta.com 、gt。

20.19 Expires

20.19は期限が切れます。

   The Expires header field gives the relative time after which the
   message (or content) expires.

Expiresヘッダーフィールドはメッセージ(または、内容)が期限が切れる相対的な時を与えます。

   The precise meaning of this is method dependent.

この正確な意味はメソッドに依存しています。

   The expiration time in an INVITE does not affect the duration of the
   actual session that may result from the invitation.  Session
   description protocols may offer the ability to express time limits on
   the session duration, however.

INVITEの満了時間は招待から生じるかもしれない実際のセッションの持続時間に影響しません。 セッション記述プロトコルはしかしながら、セッション持続時間のタイムリミットを言い表す能力を提供するかもしれません。

   The value of this field is an integral number of seconds (in decimal)
   between 0 and (2**32)-1, measured from the receipt of the request.

この分野の値は0と要求の領収書から測定された(2**32)-1の間の整数の秒(小数における)です。

Rosenberg, et. al.          Standards Track                   [Page 171]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[171ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example:

例:

      Expires: 5

期限が切れます: 5

20.20 From

20.20

   The From header field indicates the initiator of the request.  This
   may be different from the initiator of the dialog.  Requests sent by
   the callee to the caller use the callee's address in the From header
   field.

Fromヘッダーフィールドは要求の創始者を示します。 これは対話の創始者と異なっているかもしれません。 訪問される人によって訪問者に送られた要求はFromヘッダーフィールドに訪問される人のアドレスを使用します。

   The optional "display-name" is meant to be rendered by a human user
   interface.  A system SHOULD use the display name "Anonymous" if the
   identity of the client is to remain hidden.  Even if the "display-
   name" is empty, the "name-addr" form MUST be used if the "addr-spec"
   contains a comma, question mark, or semicolon.  Syntax issues are
   discussed in Section 7.3.1.

任意の「ディスプレイ名」は人間のユーザーインタフェースによってレンダリングされることになっています。 クライアントのアイデンティティが隠されたままで残るつもりであるなら、システムSHOULDは「匿名」というディスプレイ名を使用します。 「ディスプレイ名」が空であっても、「addr-仕様」がコンマ、疑問符、またはセミコロンを含んでいるなら、「名前-addr」フォームを使用しなければなりません。 セクション7.3.1で構文問題について議論します。

   Two From header fields are equivalent if their URIs match, and their
   parameters match. Extension parameters in one header field, not
   present in the other are ignored for the purposes of comparison. This
   means that the display name and presence or absence of angle brackets
   do not affect matching.

それらのURIが合っているなら、2つのFromヘッダーフィールドが同等です、そして、それらのパラメタは合っています。 もう片方におけるプレゼントではなく、1つのヘッダーフィールドにおける拡大パラメタが比較の目的のために無視されます。 これは、角ブラケットのディスプレイ名と存在か不在がマッチングに影響しないことを意味します。

   See Section 20.10 for the rules for parsing a display name, URI and
   URI parameters, and header field parameters.

ディスプレイ名、URI、URIパラメタ、およびヘッダーフィールドパラメタを分析するための規則に関してセクション20.10を見てください。

   The compact form of the From header field is f.

Fromヘッダーフィールドのコンパクト形はfです。

   Examples:

例:

      From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
      From: sip:+12125551212@server.phone2net.com;tag=887s
      f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

From: 「A。」 G。 「ベル」<一口: agb@bell-telephone.com 、gt;、;=a48s From:にタグ付けをしてください 一口: + 12125551212@server.phone2net.com;tag は887s fと等しいです: 匿名の<一口: c8oqz84zk7z@privacy.org 、gt;、;=hyh8にタグ付けをしてください

20.21 In-Reply-To

に対して20.21。

   The In-Reply-To header field enumerates the Call-IDs that this call
   references or returns.  These Call-IDs may have been cached by the
   client then included in this header field in a return call.

Inが答える、ヘッダーフィールドはこの呼び出しが参照をつけるか、または返すCall-IDを列挙します。 このヘッダーフィールドに電話連絡でその時を含んでいる場合、これらのCall-IDはクライアントによってキャッシュされたかもしれません。

      This allows automatic call distribution systems to route return
      calls to the originator of the first call.  This also allows
      callees to filter calls, so that only return calls for calls they
      originated will be accepted.  This field is not a substitute for
      request authentication.

これで、自動呼び出し流通制度は準備ラッパの創始者に電話連絡を発送できます。 また、これで、訪問される人は、それらが溯源した呼び出しのための電話連絡だけを受け入れるように呼び出しをフィルターにかけることができます。 この分野は要求認証の代用品ではありません。

Rosenberg, et. al.          Standards Track                   [Page 172]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[172ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example:

例:

      In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com

以下に対して 70710@saturn.bell-tel.com 、17320@saturn.bell-tel.com

20.22 Max-Forwards

20.22 前方へマックス

   The Max-Forwards header field must be used with any SIP method to
   limit the number of proxies or gateways that can forward the request
   to the next downstream server.  This can also be useful when the
   client is attempting to trace a request chain that appears to be
   failing or looping in mid-chain.

次の川下のサーバに要求を転送できるプロキシかゲートウェイの数を制限するどんなSIPメソッドでも前方へマックスヘッダーフィールドを使用しなければなりません。また、クライアントが、中間のチェーンで失敗するか、または輪にしているように見える要求チェーンをたどるのを試みているとき、これも役に立つ場合があります。

   The Max-Forwards value is an integer in the range 0-255 indicating
   the remaining number of times this request message is allowed to be
   forwarded.  This count is decremented by each server that forwards
   the request.  The recommended initial value is 70.

前方へマックス値は回のこの要求メッセージが進めることができる残っている数を示す範囲0-255の整数です。 このカウントは要求を転送する各サーバで減少します。 お勧めの初期の値は70です。

   This header field should be inserted by elements that can not
   otherwise guarantee loop detection.  For example, a B2BUA should
   insert a Max-Forwards header field.

このヘッダーフィールドは別の方法で輪の検出を保証できない要素によって挿入されるべきです。 例えば、B2BUAは前方へマックスヘッダーフィールドを挿入するはずです。

   Example:

例:

      Max-Forwards: 6

マックス-フォワード: 6

20.23 Min-Expires

20.23は分期限が切れます。

   The Min-Expires header field conveys the minimum refresh interval
   supported for soft-state elements managed by that server.  This
   includes Contact header fields that are stored by a registrar.  The
   header field contains a decimal integer number of seconds from 0 to
   (2**32)-1.  The use of the header field in a 423 (Interval Too Brief)
   response is described in Sections 10.2.8, 10.3, and 21.4.17.

ヘッダーフィールドは最小限を伝えます。そのサーバによって管理された軟性国家要素のためにサポートされた間隔をリフレッシュしてください。Min期限が切れる、これは記録係によって保存されるContactヘッダーフィールドを含んでいます。 ヘッダーフィールドは(2**32)に-1を0からの10進整数の秒含んでいます。 423(間隔Too Brief)応答におけるヘッダーフィールドの使用はセクション10.2.8、10.3、および21.4で.17に説明されます。

   Example:

例:

      Min-Expires: 60

分期限が切れます: 60

20.24 MIME-Version

20.24 MIMEバージョン

   See [H19.4.1].

[H19.4.1]を見てください。

   Example:

例:

      MIME-Version: 1.0

MIMEバージョン: 1.0

Rosenberg, et. al.          Standards Track                   [Page 173]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[173ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

20.25 Organization

20.25 組織

   The Organization header field conveys the name of the organization to
   which the SIP element issuing the request or response belongs.

Organizationヘッダーフィールドは要求か応答を出すSIP要素が属する組織名を伝えます。

      The field MAY be used by client software to filter calls.

分野はクライアントソフトウェアによって使用されて、呼び出しをフィルターにかけるかもしれません。

   Example:

例:

      Organization: Boxes by Bob

組織: ボブによる箱

20.26 Priority

20.26 優先権

   The Priority header field indicates the urgency of the request as
   perceived by the client.  The Priority header field describes the
   priority that the SIP request should have to the receiving human or
   its agent.  For example, it may be factored into decisions about call
   routing and acceptance.  For these decisions, a message containing no
   Priority header field SHOULD be treated as if it specified a Priority
   of "normal".  The Priority header field does not influence the use of
   communications resources such as packet forwarding priority in
   routers or access to circuits in PSTN gateways.  The header field can
   have the values "non-urgent", "normal", "urgent", and "emergency",
   but additional values can be defined elsewhere.  It is RECOMMENDED
   that the value of "emergency" only be used when life, limb, or
   property are in imminent danger.  Otherwise, there are no semantics
   defined for this header field.

クライアントによって知覚されるようにPriorityヘッダーフィールドは要求の緊急を示します。 PriorityヘッダーフィールドはSIP要求が受信人間かそのエージェントに持つべきである優先権について説明します。 例えば、呼び出しルーティングと承認に関する決定はそれの要因として考慮されるかもしれません。 これらの決定、PriorityヘッダーフィールドがないSHOULDを含むメッセージに関しては、まるで「標準」のPriorityを指定するかのように、扱われてください。 Priorityヘッダーフィールドはルータにおけるパケット推進優先権かPSTNゲートウェイの回路へのアクセスなどのコミュニケーションリソースの使用に影響を及ぼしません。 ヘッダーフィールドは「不急」で、「正常で」、「緊急」に値を持つことができます、そして、ほかの場所で「非常時」の、しかし、追加している値は定義できます。 急迫の危険に寿命、手足、または特性があるとき、「非常時」の値が使用されるだけであるのは、RECOMMENDEDです。 さもなければ、このヘッダーフィールドのために定義された意味論が全くありません。

      These are the values of RFC 2076 [38], with the addition of
      "emergency".

これらは「非常時」の追加があるRFC2076[38]の値です。

   Examples:

例:

      Subject: A tornado is heading our way!
      Priority: emergency

Subject: 竜巻は私たちのやり方の上に立っています! 優先権: 非常時

   or

または

      Subject: Weekend plans
      Priority: non-urgent

Subject: 週末はPriorityを計画しています: 不急

20.27 Proxy-Authenticate

20.27はプロキシで認証します。

   A Proxy-Authenticate header field value contains an authentication
   challenge.

Aはヘッダーフィールド値をProxy認証します。認証挑戦を含んでいます。

   The use of this header field is defined in [H14.33].  See Section
   22.3 for further details on its usage.

このヘッダーフィールドの使用は[H14.33]で定義されます。 さらに詳しい明細については用法のセクション22.3を見てください。

Rosenberg, et. al.          Standards Track                   [Page 174]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[174ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example:

例:

      Proxy-Authenticate: Digest realm="atlanta.com",
       domain="sip:ss1.carrier.com", qop="auth",
       nonce="f84f1cec41e6cbe5aea9c8e88d359",
       opaque="", stale=FALSE, algorithm=MD5

以下をプロキシで認証してください。 「ダイジェスト分野="atlanta.com"ドメイン=「一口: ss1.carrier.com」、qop="auth"一回だけ="f84f1cec41e6cbe5aea9c8e88d359"は=について不透明にする」、」、= 虚偽で古くさくなってください、そして、アルゴリズムはMD5と等しいです。

20.28 Proxy-Authorization

20.28 プロキシ承認

   The Proxy-Authorization header field allows the client to identify
   itself (or its user) to a proxy that requires authentication.  A
   Proxy-Authorization field value consists of credentials containing
   the authentication information of the user agent for the proxy and/or
   realm of the resource being requested.

Proxy-承認ヘッダーフィールドで、クライアントは身元(または、ユーザ)を認証を必要とするプロキシに明らかにすることができます。 Proxy-承認分野価値は要求されているリソースのプロキシ、そして/または、分野にユーザエージェントの認証情報を含む資格証明書から成ります。

   See Section 22.3 for a definition of the usage of this header field.

このヘッダーフィールドの用法の定義に関してセクション22.3を見てください。

   This header field, along with Authorization, breaks the general rules
   about multiple header field names.  Although not a comma-separated
   list, this header field name may be present multiple times, and MUST
   NOT be combined into a single header line using the usual rules
   described in Section 7.3.1.

このヘッダーフィールドはAuthorizationと共に複数のヘッダーフィールド名に関する総則を破ります。 コンマで切り離されたリストではありませんが、このヘッダーフィールド名は、プレゼント複数の回であるかもしれなく、セクション7.3.1で説明された普通の規則を使用することでただ一つのヘッダー系列に結合されてはいけません。

   Example:

例:

   Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
      nonce="c60f3082ee1212b402a21831ae",
      response="245f23415f11432b3434341c022"

プロキシ承認: ユーザ名=「アリス」、分野="atlanta.com"一回だけ="c60f3082ee1212b402a21831ae"を読みこなしてください、そして、応答は"245f23415f11432b3434341c022""と等しいです。

20.29 Proxy-Require

20.29がプロキシで必要です。

   The Proxy-Require header field is used to indicate proxy-sensitive
   features that must be supported by the proxy.  See Section 20.32 for
   more details on the mechanics of this message and a usage example.

使用されるヘッダーフィールドがプロキシがサポートしなければならないプロキシ機密の特徴を示すのをProxy必要であってください。 このメッセージと使用例の整備士に関するその他の詳細に関してセクション20.32を見てください。

   Example:

例:

      Proxy-Require: foo

以下をプロキシで必要としてください。 foo

20.30 Record-Route

20.30の記録的なルート

   The Record-Route header field is inserted by proxies in a request to
   force future requests in the dialog to be routed through the proxy.

Record-ルートヘッダーフィールドはプロキシによって対話における今後の要求がプロキシを通して発送させられるという要求に挿入されます。

   Examples of its use with the Route header field are described in
   Sections 16.12.1.

Routeヘッダーフィールドがある使用に関する例はセクション16.12.1で説明されます。

Rosenberg, et. al.          Standards Track                   [Page 175]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[175ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example:

例:

      Record-Route: <sip:server10.biloxi.com;lr>,
                    <sip:bigbox3.site3.atlanta.com;lr>

記録的なルート: <一口: server10.biloxi.com; <一口: lr>、bigbox3.site3.atlanta.com; lr>。

20.31 Reply-To

20.31は答えます。

   The Reply-To header field contains a logical return URI that may be
   different from the From header field.  For example, the URI MAY be
   used to return missed calls or unestablished sessions.  If the user
   wished to remain anonymous, the header field SHOULD either be omitted
   from the request or populated in such a way that does not reveal any
   private information.

Reply、-、ヘッダーフィールドはFromヘッダーフィールドと異なるかもしれない論理的なリターンURIを含んでいます。 例えば、URIは、逃された呼び出しか非設立されたセッションを返すのに使用されるかもしれません。 匿名のままで残っていることが願われていたユーザ、ヘッダーフィールドSHOULDが要求から省略されるかそのような方法で居住されているなら、それは少しの個人情報も明らかにしません。

   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or
   semicolon.  Syntax issues are discussed in Section 7.3.1.

「ディスプレイ名」が空であっても、「addr-仕様」がコンマ、疑問符、またはセミコロンを含んでいるなら、「名前-addr」フォームを使用しなければなりません。 セクション7.3.1で構文問題について議論します。

   Example:

例:

      Reply-To: Bob <sip:bob@biloxi.com>

Reply-To ボブ<一口: bob@biloxi.com 、gt。

20.32 Require

20.32が必要です。

   The Require header field is used by UACs to tell UASs about options
   that the UAC expects the UAS to support in order to process the
   request.  Although an optional header field, the Require MUST NOT be
   ignored if it is present.

Requireヘッダーフィールドは、UACが、UASが要求を処理するためにサポートすると予想するオプションに関してUASsに話すのにUACsによって使用されます。 任意のヘッダーフィールドですが、それが存在しているなら、Requireを無視してはいけません。

   The Require header field contains a list of option tags, described in
   Section 19.2.  Each option tag defines a SIP extension that MUST be
   understood to process the request.  Frequently, this is used to
   indicate that a specific set of extension header fields need to be
   understood.  A UAC compliant to this specification MUST only include
   option tags corresponding to standards-track RFCs.

Requireヘッダーフィールドはセクション19.2で説明されたオプションタグのリストを含んでいます。 それぞれのオプションタグは要求を処理するのを理解しなければならないSIP拡張子を定義します。 頻繁に、これは、特定の拡大ヘッダーフィールドが、理解される必要であるのを示すのに使用されます。 この仕様に言いなりになっているUACは標準化過程RFCsに対応するオプションタグを含むだけでよいです。

   Example:

例:

      Require: 100rel

必要です: 100rel

20.33 Retry-After

20.33 再試行します。

   The Retry-After header field can be used with a 500 (Server Internal
   Error) or 503 (Service Unavailable) response to indicate how long the
   service is expected to be unavailable to the requesting client and
   with a 404 (Not Found), 413 (Request Entity Too Large), 480
   (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603

どれくらい長い間サービスが要求しているクライアント、およびa404(Foundでない)、413(Entity Too Largeを要求する)による480を入手できないと予想されるかを示すのに500(サーバInternal Error)か503(サービスUnavailable)応答と共に後のRetryヘッダーフィールドを使用できる、(一時的である、Unavailable)、486、(忙しいHere)、600(忙しい)か603

Rosenberg, et. al.          Standards Track                   [Page 176]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[176ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   (Decline) response to indicate when the called party anticipates
   being available again.  The value of this field is a positive integer
   number of seconds (in decimal) after the time of the response.

被呼者であるときに示す(衰退)応答は、再び利用可能であると予期します。 この分野の値は応答の時間の何秒も正の整数番号の後(小数における)です。

   An optional comment can be used to indicate additional information
   about the time of callback.  An optional "duration" parameter
   indicates how long the called party will be reachable starting at the
   initial time of availability.  If no duration parameter is given, the
   service is assumed to be available indefinitely.

コールバックの時頃に追加情報を示すのに任意のコメントを使用できます。 任意の「持続時間」パラメタは、有用性の初回で始まって、被呼者にどれくらい長い間届くかを示します。 持続時間パラメタを全く与えないなら、無期限に利用可能であるとサービスを思います。

   Examples:

例:

      Retry-After: 18000;duration=3600
      Retry-After: 120 (I'm in a meeting)

-後に再試行してください: 18000; 持続時間は後の3600年の再試行と等しいです: 120 (私はミーティングでいます)

20.34 Route

20.34ルート

   The Route header field is used to force routing for a request through
   the listed set of proxies.  Examples of the use of the Route header
   field are in Section 16.12.1.

Routeヘッダーフィールドは、記載されたプロキシを通して要求のためのルーティングを強制するのに使用されます。 セクション16.12.1にはRouteヘッダーフィールドの使用に関する例があります。

   Example:

例:

      Route: <sip:bigbox3.site3.atlanta.com;lr>,
             <sip:server10.biloxi.com;lr>

以下を発送してください。 <一口: bigbox3.site3.atlanta.com; <一口: lr>、server10.biloxi.com; lr>。

20.35 Server

20.35 サーバ

   The Server header field contains information about the software used
   by the UAS to handle the request.

Serverヘッダーフィールドは要求を扱うのにUASによって使用されたソフトウェアの情報を含んでいます。

   Revealing the specific software version of the server might allow the
   server to become more vulnerable to attacks against software that is
   known to contain security holes.  Implementers SHOULD make the Server
   header field a configurable option.

サーバの特定のソフトウェアバージョンを明らかにすることによって、サーバはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなるかもしれません。 Implementers SHOULDはServerヘッダーフィールドを構成可能なオプションにします。

   Example:

例:

      Server: HomeServer v2

サーバ: HomeServer v2

20.36 Subject

20.36 対象

   The Subject header field provides a summary or indicates the nature
   of the call, allowing call filtering without having to parse the
   session description.  The session description does not have to use
   the same subject indication as the invitation.

Subjectヘッダーフィールドは、概要を提供するか、または呼び出しの本質を示します、セッション記述を分析する必要はなくて呼び出しフィルタリングを許容して。 セッション記述は招待と同じ対象の指示を使用する必要はありません。

   The compact form of the Subject header field is s.

Subjectヘッダーフィールドのコンパクト形はsです。

Rosenberg, et. al.          Standards Track                   [Page 177]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[177ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Example:

例:

      Subject: Need more boxes
      s: Tech Support

Subject: より多くの箱s:でなければならない テクニカル・サポート

20.37 Supported

20.37 サポートされました。

   The Supported header field enumerates all the extensions supported by
   the UAC or UAS.

SupportedヘッダーフィールドはUACかUASによってサポートされたすべての拡大を列挙します。

   The Supported header field contains a list of option tags, described
   in Section 19.2, that are understood by the UAC or UAS.  A UA
   compliant to this specification MUST only include option tags
   corresponding to standards-track RFCs.  If empty, it means that no
   extensions are supported.

SupportedヘッダーフィールドはUACかUASに解釈されるセクション19.2で説明されたオプションタグのリストを含んでいます。 この仕様に言いなりになっているUAは標準化過程RFCsに対応するオプションタグを含むだけでよいです。 空であるなら、それは、拡大が全くサポートされないことを意味します。

   The compact form of the Supported header field is k.

Supportedヘッダーフィールドのコンパクト形はkです。

   Example:

例:

      Supported: 100rel

サポートされる: 100rel

20.38 Timestamp

20.38 タイムスタンプ

   The Timestamp header field describes when the UAC sent the request to
   the UAS.

Timestampヘッダーフィールドは、UACがいつ要求をUASに送ったかを説明します。

   See Section 8.2.6 for details on how to generate a response to a
   request that contains the header field.  Although there is no
   normative behavior defined here that makes use of the header, it
   allows for extensions or SIP applications to obtain RTT estimates.

どうヘッダーフィールドを含む要求への応答を生成するかに関する詳細に関してセクション8.2.6を見てください。 ヘッダーを利用するここで定義されたどんな標準の振舞いもありませんが、拡大かSIPアプリケーションがRTT見積りを得るのをそれは、許容します。

   Example:

例:

      Timestamp: 54

タイムスタンプ: 54

20.39 To

20.39

   The To header field specifies the logical recipient of the request.

Toヘッダーフィールドは要求の論理的な受取人を指定します。

   The optional "display-name" is meant to be rendered by a human-user
   interface.  The "tag" parameter serves as a general mechanism for
   dialog identification.

任意の「ディスプレイ名」は人間のユーザーインタフェースによってレンダリングされることになっています。 「タグ」パラメタは対話識別のための一般的機構として機能します。

   See Section 19.3 for details of the "tag" parameter.

「タグ」パラメタの詳細に関してセクション19.3を見てください。

Rosenberg, et. al.          Standards Track                   [Page 178]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[178ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Comparison of To header fields for equality is identical to
   comparison of From header fields.  See Section 20.10 for the rules
   for parsing a display name, URI and URI parameters, and header field
   parameters.

平等のためのToヘッダーフィールドの比較はFromヘッダーフィールドの比較と同じです。 ディスプレイ名、URI、URIパラメタ、およびヘッダーフィールドパラメタを分析するための規則に関してセクション20.10を見てください。

   The compact form of the To header field is t.

Toヘッダーフィールドのコンパクト形はtです。

   The following are examples of valid To header fields:

↓これは有効なToヘッダーフィールドに関する例です:

      To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
      t: sip:+12125551212@server.phone2net.com

To: Operator<一口: operator@cs.columbia.edu 、gt;、; =287447tにタグ付けをしてください: 一口: + 12125551212@server.phone2net.com

20.40 Unsupported

20.40、サポートされなさ

   The Unsupported header field lists the features not supported by the
   UAS.  See Section 20.32 for motivation.

UnsupportedヘッダーフィールドはUASによってサポートされなかった特徴をリストアップします。 動機に関してセクション20.32を見てください。

   Example:

例:

      Unsupported: foo

サポートされない: foo

20.41 User-Agent

20.41 ユーザエージェント

   The User-Agent header field contains information about the UAC
   originating the request.  The semantics of this header field are
   defined in [H14.43].

User-エージェントヘッダーフィールドは要求を溯源するUACの情報を含んでいます。 このヘッダーフィールドの意味論は[H14.43]で定義されます。

   Revealing the specific software version of the user agent might allow
   the user agent to become more vulnerable to attacks against software
   that is known to contain security holes.  Implementers SHOULD make
   the User-Agent header field a configurable option.

ユーザエージェントの特定のソフトウェアバージョンを明らかにするのに、ユーザエージェントはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなることができるかもしれません。 Implementers SHOULDはUser-エージェントヘッダーフィールドを構成可能なオプションにします。

   Example:

例:

      User-Agent: Softphone Beta1.5

ユーザエージェント: ソフトフォンBeta1.5

20.42 Via

を通して20.42。

   The Via header field indicates the path taken by the request so far
   and indicates the path that should be followed in routing responses.
   The branch ID parameter in the Via header field values serves as a
   transaction identifier, and is used by proxies to detect loops.

Viaヘッダーフィールドは、今までのところ要求で取られている経路を示して、ルーティング応答で続くべきである経路を示します。 Viaヘッダーフィールド値におけるブランチIDパラメタは、トランザクション識別子として勤めて、輪を検出するのにプロキシによって使用されます。

   A Via header field value contains the transport protocol used to send
   the message, the client's host name or network address, and possibly
   the port number at which it wishes to receive responses.  A Via
   header field value can also contain parameters such as "maddr",
   "ttl", "received", and "branch", whose meaning and use are described

Viaヘッダーフィールド価値はメッセージ、クライアントのホスト名またはネットワーク・アドレスを送るのに使用されるトランスポート・プロトコル、およびことによるとそれが応答を受けたがっているポートナンバーを含んでいます。 また、Viaヘッダーフィールド価値は「受信する」という"maddr"、"ttl"などのパラメタ、および意味と使用が説明される「ブランチ」を含むことができます。

Rosenberg, et. al.          Standards Track                   [Page 179]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[179ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   in other sections.  For implementations compliant to this
   specification, the value of the branch parameter MUST start with the
   magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.

他のセクションで。 この仕様への対応することの実装のために、ブランチパラメタの値は魔法のクッキー"z9hG4bK"から始まらなければなりません、セクション8.1.1で.7に議論するように

   Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
   "TLS" means TLS over TCP.  When a request is sent to a SIPS URI, the
   protocol still indicates "SIP", and the transport protocol is TLS.

ここで定義されたトランスポート・プロトコルは、"UDP"と、"TCP"と、「TLS」と、"SCTP"です。 「TLS」はTCPの上でTLSを意味します。 SIPS URIに要求を送るとき、プロトコルはまだ「一口」を示しています、そして、トランスポート・プロトコルはTLSです。

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
     ;branch=z9hG4bK77asjd

以下を通って 一口/2.0/UDP erlang.bell-telephone.com: 5060; ブランチは以下を通ってz9hG4bK87asdks7と等しいです。 一口/2.0/UDP192.0.2.1: 5060; 容認された=192.0.2、.207;ブランチ=z9hG4bK77asjd

   The compact form of the Via header field is v.

Viaヘッダーフィールドのコンパクト形はvです。

   In this example, the message originated from a multi-homed host with
   two addresses, 192.0.2.1 and 192.0.2.207.  The sender guessed wrong
   as to which network interface would be used.  Erlang.bell-
   telephone.com noticed the mismatch and added a parameter to the
   previous hop's Via header field value, containing the address that
   the packet actually came from.

そして、この例では、メッセージがaから発した、マルチ、家へ帰り、2つのアドレス、192.0で.2を接待してください、.1、192.0 .2 .207。 どのネットワーク・インターフェースが使用されるだろうかに関して送付者は勘違いしました。 Erlang.bell telephone.comは前のホップのViaヘッダーフィールド価値にミスマッチに気付いて、パラメタを加えました、パケットが実際に来たアドレスを含んでいて。

   The host or network address and port number are not required to
   follow the SIP URI syntax.  Specifically, LWS on either side of the
   ":" or "/" is allowed, as shown here:

ホストかネットワーク・アドレスとポートナンバーは、SIP URI構文に従うのに必要ではありません。 「明確に、どちらかのLWSは面がある、」、:、」 「」 /、」 ここに示されるように、許容されています:

      Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
        ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1

以下を通って SIP/2.0/UDP最初の.example.com: 4000; ttl=16; maddr=224.2.0.1; ブランチ=z9hG4bKa7c6a8dlze.1

   Even though this specification mandates that the branch parameter be
   present in all requests, the BNF for the header field indicates that
   it is optional.  This allows interoperation with RFC 2543 elements,
   which did not have to insert the branch parameter.

この仕様ですが、ヘッダーフィールドが、それが任意であることを示すので、ブランチパラメタをある命令がすべてで要求、BNFを寄贈します。 これはRFC2543要素でinteroperationを許容します。(要素はブランチパラメタを挿入する必要はありませんでした)。

   Two Via header fields are equal if their sent-protocol and sent-by
   fields are equal, both have the same set of parameters, and the
   values of all parameters are equal.

2Viaヘッダー、分野はそれらの送られたプロトコルであるなら等しく、送って、分野は等しく、両方には、同じセットのパラメタがあって、すべてのパラメタの値は等しいです。

20.43 Warning

20.43 警告

   The Warning header field is used to carry additional information
   about the status of a response.  Warning header field values are sent
   with responses and contain a three-digit warning code, host name, and
   warning text.

Warningヘッダーフィールドは、応答の状態に関する追加情報を運ぶのに使用されます。 警告ヘッダーフィールド値は、応答と共に送られて、3ケタの警告コード、ホスト名、および警告テキストを含んでいます。

   The "warn-text" should be in a natural language that is most likely
   to be intelligible to the human user receiving the response.  This
   decision can be based on any available knowledge, such as the
   location of the user, the Accept-Language field in a request, or the

「警告する、」 応答を受ける人間のユーザにとって明瞭である最も傾向がある自然言語にはあるべきです。 またはこの決定はどんな利用可能な知識にも基づくことができます、ユーザの位置などのように、要求におけるAccept-言語分野。

Rosenberg, et. al.          Standards Track                   [Page 180]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[180ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   Content-Language field in a response.  The default language is i-
   default [21].

応答における満足している言語分野。 デフォルト言語はiデフォルト[21]です。

   The currently-defined "warn-code"s are listed below, with a
   recommended warn-text in English and a description of their meaning.
   These warnings describe failures induced by the session description.
   The first digit of warning codes beginning with "3" indicates
   warnings specific to SIP.  Warnings 300 through 329 are reserved for
   indicating problems with keywords in the session description, 330
   through 339 are warnings related to basic network services requested
   in the session description, 370 through 379 are warnings related to
   quantitative QoS parameters requested in the session description, and
   390 through 399 are miscellaneous warnings that do not fall into one
   of the above categories.

現在定義にされる、「警告する、aがお勧めで」 sが以下に記載されている、警告する、それらの意味の英語と記述で。 これらの警告はセッション記述で引き起こされた失敗について説明します。 警告の最初のケタは「3インチはちびちび飲むために特定の警告を示すこと」で始めをコード化します。 警告300〜329はセッション記述におけるキーワードに関する問題を示すために予約されます、そして、330〜339はセッション記述で要求された基本的なネットワーク・サービスに関連する警告です、そして、370〜379はセッション記述で要求された量的なQoSパラメタに関連する警告です、そして、390〜399は上のカテゴリの1つにならない種々雑多な警告です。

      300 Incompatible network protocol: One or more network protocols
          contained in the session description are not available.

300 両立しないネットワーク・プロトコル: セッション記述に含まれた1つ以上のネットワーク・プロトコルは利用可能ではありません。

      301 Incompatible network address formats: One or more network
          address formats contained in the session description are not
          available.

301 両立しないネットワークアドレス形式: セッション記述に含まれた1つ以上のネットワークアドレス形式は利用可能ではありません。

      302 Incompatible transport protocol: One or more transport
          protocols described in the session description are not
          available.

302 両立しないトランスポート・プロトコル: セッション記述で説明された1つ以上のトランスポート・プロトコルは利用可能ではありません。

      303 Incompatible bandwidth units: One or more bandwidth
          measurement units contained in the session description were
          not understood.

303 両立しない帯域幅ユニット: セッション記述に含まれた複数の帯域幅測定単位は理解されていませんでした。

      304 Media type not available: One or more media types contained in
          the session description are not available.

304のメディアが利用可能でなくタイプします: セッション記述に含まれた1つ以上のメディアタイプは手があいていません。

      305 Incompatible media format: One or more media formats contained
          in the session description are not available.

305 両立しないメディア形式: セッション記述に含まれた1つ以上のメディア形式は利用可能ではありません。

      306 Attribute not understood: One or more of the media attributes
          in the session description are not supported.

306属性は分かりませんでした: セッション記述におけるメディア属性は、1つかもうサポートされません。

      307 Session description parameter not understood: A parameter
          other than those listed above was not understood.

307セッション記述パラメタは分かりませんでした: 上に記載されたもの以外のパラメタは理解されていませんでした。

      330 Multicast not available: The site where the user is located
          does not support multicast.

利用可能でない330マルチキャスト: ユーザが位置しているサイトはマルチキャストをサポートしません。

      331 Unicast not available: The site where the user is located does
          not support unicast communication (usually due to the presence
          of a firewall).

利用可能でない331ユニキャスト: ユーザが位置しているサイトはユニキャストコミュニケーション(通常ファイアウォールの存在による)をサポートしません。

Rosenberg, et. al.          Standards Track                   [Page 181]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[181ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

      370 Insufficient bandwidth: The bandwidth specified in the session
          description or defined by the media exceeds that known to be
          available.

370 不十分な帯域幅: セッション記述で指定されたか、またはメディアによって定義された帯域幅は利用可能であることが知られているそれを超えています。

      399 Miscellaneous warning: The warning text can include arbitrary
          information to be presented to a human user or logged.  A
          system receiving this warning MUST NOT take any automated
          action.

399 種々雑多な警告: 警告テキストは、人間のユーザに提示されるか、または登録されるために任意の情報を含むことができます。 この警告を受け取るシステムは少しの自動化された行動も取ってはいけません。

             1xx and 2xx have been taken by HTTP/1.1.

1xxと2xxをHTTP/1.1取りました。

   Additional "warn-code"s can be defined through IANA, as defined in
   Section 27.2.

追加、「警告する、」 セクション27.2で定義されるようにIANAを通してsを定義できます。

   Examples:

例:

      Warning: 307 isi.edu "Session parameter 'foo' not understood"
      Warning: 301 isi.edu "Incompatible network address type 'E.164'"

警告: 307 isi.edu「セッションパラメタ'fooはWarningを'理解していませんでした」: 301 isi.edu「非互換なネットワークアドレスタイプ'E.164'」

20.44 WWW-Authenticate

20.44はWWW認証します。

   A WWW-Authenticate header field value contains an authentication
   challenge.  See Section 22.2 for further details on its usage.

Aはヘッダーフィールド値をWWW認証します。認証挑戦を含んでいます。 さらに詳しい明細については用法のセクション22.2を見てください。

   Example:

例:

      WWW-Authenticate: Digest realm="atlanta.com",
        domain="sip:boxesbybob.com", qop="auth",
        nonce="f84f1cec41e6cbe5aea9c8e88d359",
        opaque="", stale=FALSE, algorithm=MD5

以下をWWW認証してください。 「ダイジェスト分野="atlanta.com"ドメイン=「一口: boxesbybob.com」、qop="auth"一回だけ="f84f1cec41e6cbe5aea9c8e88d359"は=について不透明にする」、」、= 虚偽で古くさくなってください、そして、アルゴリズムはMD5と等しいです。

21 Response Codes

21 応答コード

   The response codes are consistent with, and extend, HTTP/1.1 response
   codes.  Not all HTTP/1.1 response codes are appropriate, and only
   those that are appropriate are given here.  Other HTTP/1.1 response
   codes SHOULD NOT be used.  Also, SIP defines a new class, 6xx.

HTTP/1.1に広がってください。そして、コードが一致している応答、応答コード。 すべてのHTTP/1.1の応答コードがどんな適切であるというわけではありません、そして、適切なものだけをここに与えます。 他のHTTP/1.1応答はSHOULD NOTをコード化します。使用されます。 また、SIPは新しいクラス、6xxを定義します。

21.1 Provisional 1xx

21.1 暫定的な1xx

   Provisional responses, also known as informational responses,
   indicate that the server contacted is performing some further action
   and does not yet have a definitive response.  A server sends a 1xx
   response if it expects to take more than 200 ms to obtain a final
   response.  Note that 1xx responses are not transmitted reliably.
   They never cause the client to send an ACK.  Provisional (1xx)
   responses MAY contain message bodies, including session descriptions.

暫定的なまた、情報の応答として知られている応答は、連絡されたサーバがさらなる何らかの動作を実行していて、まだ決定的な応答を持っていないのを示します。 それが、最終的な応答を得るために200以上msを取ると予想するなら、サーバは1xx応答を送ります。 1xx応答が確かに伝えられないことに注意してください。 彼らはクライアントにACKを決して送らせません。 暫定的な(1xx)応答はセッション記述を含むメッセージ本体を含むかもしれません。

Rosenberg, et. al.          Standards Track                   [Page 182]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[182ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

21.1.1 100 Trying

21.1.1 100 トライ

   This response indicates that the request has been received by the
   next-hop server and that some unspecified action is being taken on
   behalf of this call (for example, a database is being consulted).
   This response, like all other provisional responses, stops
   retransmissions of an INVITE by a UAC.  The 100 (Trying) response is
   different from other provisional responses, in that it is never
   forwarded upstream by a stateful proxy.

この応答は次のホップサーバで要求を受け取って、この呼び出しを代表して何らかの不特定の行動を取っているのを示します(例えば、データベースは相談されています)。 他のすべての暫定的な応答のように、この応答はUACでINVITEの「再-トランスミッション」を止めます。 100の(試みること)の応答は他の暫定的な応答と異なっています、それがstatefulプロキシによって決して上流へ進められないので。

21.1.2 180 Ringing

21.1.2 180 鳴ること

   The UA receiving the INVITE is trying to alert the user.  This
   response MAY be used to initiate local ringback.

INVITEを受けるUAはユーザを警告しようとしています。 この応答は、地方のringbackを開始するのに使用されるかもしれません。

21.1.3 181 Call Is Being Forwarded

21.1.3 181 呼び出しを進めています。

   A server MAY use this status code to indicate that the call is being
   forwarded to a different set of destinations.

サーバは、呼び出しが異なったセットの目的地に送られているのを示すのにこのステータスコードを使用するかもしれません。

21.1.4 182 Queued

21.1.4 182 列に並ばせられます。

   The called party is temporarily unavailable, but the server has
   decided to queue the call rather than reject it.  When the callee
   becomes available, it will return the appropriate final status
   response.  The reason phrase MAY give further details about the
   status of the call, for example, "5 calls queued; expected waiting
   time is 15 minutes".  The server MAY issue several 182 (Queued)
   responses to update the caller about the status of the queued call.

被呼者は一時入手できないのですが、サーバは、それを拒絶するよりむしろ呼び出しを列に並ばせると決めました。 訪問される人が利用可能になると、それは適切な最終的な状態応答を返すでしょう。 理由句は呼び出しの状態に関する詳細を与えるかもしれません、例えば、「5つの呼び出しが列を作りました」。 「予想された待ち時間は15分です。」 サーバは、列に並ばせられた呼び出しの状態に関して訪問者をアップデートするために数182(列に並ばせられる)の応答を発行するかもしれません。

21.1.5 183 Session Progress

21.1.5 183 セッション進歩

   The 183 (Session Progress) response is used to convey information
   about the progress of the call that is not otherwise classified.  The
   Reason-Phrase, header fields, or message body MAY be used to convey
   more details about the call progress.

183(セッションProgress)応答は、別の方法で分類されない呼び出しの進歩に関して情報を伝達するのに使用されます。 Reason-句、ヘッダーフィールド、またはメッセージ本体が、呼び出し進歩に関するその他の詳細を伝えるのに使用されるかもしれません。

21.2 Successful 2xx

21.2 うまくいっている2xx

   The request was successful.

要求はうまくいきました。

21.2.1 200 OK

21.2.1 200 OK

   The request has succeeded.  The information returned with the
   response depends on the method used in the request.

要求は成功しました。 応答と共に返された情報は要求で使用されるメソッドによります。

Rosenberg, et. al.          Standards Track                   [Page 183]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[183ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

21.3 Redirection 3xx

21.3 リダイレクション3xx

   3xx responses give information about the user's new location, or
   about alternative services that might be able to satisfy the call.

3xx応答はユーザの新しい位置の周り、または、呼び出しを満たすことができるかもしれない代替のサービスの周りに関して知らせます。

21.3.1 300 Multiple Choices

21.3.1 300 選択式

   The address in the request resolved to several choices, each with its
   own specific location, and the user (or UA) can select a preferred
   communication end point and redirect its request to that location.

いくつかの選択に決議された要求におけるアドレス、それ自身の特定の位置があるそれぞれ、およびユーザ(または、UA)は、都合のよいコミュニケーションエンドポイントを選択して、その位置に要求を向け直すことができます。

   The response MAY include a message body containing a list of resource
   characteristics and location(s) from which the user or UA can choose
   the one most appropriate, if allowed by the Accept request header
   field.  However, no MIME types have been defined for this message
   body.

応答はリソースの特性のリストを含むメッセージ本体とユーザかUAが最も適切な状態でものを選ぶことができる位置を含むかもしれません、Accept要求ヘッダーフィールドによって許容されているなら。 しかしながら、MIMEの種類は全くこのメッセージ本体のために定義されていません。

   The choices SHOULD also be listed as Contact fields (Section 20.10).
   Unlike HTTP, the SIP response MAY contain several Contact fields or a
   list of addresses in a Contact field.  UAs MAY use the Contact header
   field value for automatic redirection or MAY ask the user to confirm
   a choice.  However, this specification does not define any standard
   for such automatic selection.

選択SHOULD、また、Contactが(セクション20.10)をさばくので、記載されてください。 HTTPと異なって、SIP応答はContact分野にいくつかのContact分野か住所録を保管するかもしれません。 UAsは、自動リダイレクションにContactヘッダーフィールド価値を使用するか、または選択を確認するようにユーザに頼むかもしれません。 しかしながら、この仕様はそのような自動選択のどんな規格も定義しません。

      This status response is appropriate if the callee can be reached
      at several different locations and the server cannot or prefers
      not to proxy the request.

この状態応答は、訪問される人にいくつかの別の場所で達することができて、サーバが適切であることができないなら適切であるか、またはどんなプロキシほども要求を好みません。

21.3.2 301 Moved Permanently

21.3.2 301 永久に、動きます。

   The user can no longer be found at the address in the Request-URI,
   and the requesting client SHOULD retry at the new address given by
   the Contact header field (Section 20.10).  The requestor SHOULD
   update any local directories, address books, and user location caches
   with this new value and redirect future requests to the address(es)
   listed.

もうRequest-URIにおけるアドレスでユーザを見つけることができません、そして、要求しているクライアントSHOULDはContactヘッダーフィールド(セクション20.10)によって与えられた新しいアドレスで再試行します。 要請者SHOULDはこの新しい値でどんなローカルディレクトリ、アドレス帳、およびユーザ位置のキャッシュもアップデートします、そして、アドレス(es)への再直接の今後の要求はリストアップされました。

21.3.3 302 Moved Temporarily

21.3.3 302 一時動かされました。

   The requesting client SHOULD retry the request at the new address(es)
   given by the Contact header field (Section 20.10).  The Request-URI
   of the new request uses the value of the Contact header field in the
   response.

要求しているクライアントSHOULDはContactヘッダーフィールド(セクション20.10)によって与えられた新しいアドレス(es)で要求を再試行します。 新しい要求のRequest-URIは応答における、Contactヘッダーフィールドの値を使用します。

Rosenberg, et. al.          Standards Track                   [Page 184]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[184ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

   The duration of the validity of the Contact URI can be indicated
   through an Expires (Section 20.19) header field or an expires
   parameter in the Contact header field.  Both proxies and UAs MAY
   cache this URI for the duration of the expiration time.  If there is
   no explicit expiration time, the address is only valid once for
   recursing, and MUST NOT be cached for future transactions.

または、Expires(セクション20.19)ヘッダーフィールドを通してContact URIの正当性の持続時間を示すことができる、Contactヘッダーフィールドにおけるパラメタを吐き出します。 プロキシとUAsの両方が満了時間の持続時間のためにこのURIをキャッシュするかもしれません。 どんな明白な満了時間もなければ、アドレスは、単に「再-呪」うのにかつて有効であり、清算取引のためにキャッシュされてはいけません。

   If the URI cached from the Contact header field fails, the Request-
   URI from the redirected request MAY be tried again a single time.

向け直された要求からのヘッダーフィールドやり損ない、Request URIがそうするContactからキャッシュされたURIが再び試験済みであるなら、シングルは調節されます。

      The temporary URI may have become out-of-date sooner than the
      expiration time, and a new temporary URI may be available.

一時的なURIは満了時間より早く時代遅れになったかもしれません、そして、新しい一時的なURIは利用可能であるかもしれません。

21.3.4 305 Use Proxy

21.3.4 305 プロキシを使用してください。

   The requested resource MUST be accessed through the proxy given by
   the Contact field.  The Contact field gives the URI of the proxy.
   The recipient is expected to repeat this single request via the
   proxy.  305 (Use Proxy) responses MUST only be generated by UASs.

Contact分野によって与えられるプロキシを通して要求されたリソースにアクセスしなければなりません。 Contact分野はプロキシのURIを与えます。 受取人がプロキシを通してこのただ一つの要求を繰り返すと予想されます。 305 (Proxyを使用します) UASsは応答を生成するだけでよいです。

21.3.5 380 Alternative Service

21.3.5 380 代替のサービス

   The call was not successful, but alternative services are possible.

呼び出しはうまくいきませんでしたが、代替のサービスは可能です。

   The alternative services are described in the message body of the
   response.  Formats for such bodies are not defined here, and may be
   the subject of future standardization.

代替のサービスは応答のメッセージ本体で説明されます。 そのようなボディーのための形式は、ここで定義されないで、今後の標準化の対象であるかもしれません。

21.4 Request Failure 4xx

21.4 要求失敗4xx

   4xx responses are definite failure responses from a particular
   server.  The client SHOULD NOT retry the same request without
   modification (for example, adding appropriate authorization).
   However, the same request to a different server might be successful.

4xx応答は特定のサーバからの明確な失敗応答です。クライアントSHOULD NOTは変更(例えば、適切な承認を加える)なしで同じ要求を再試行します。 しかしながら、異なったサーバへの同じ要求はうまくいっているかもしれません。

21.4.1 400 Bad Request

21.4.1 400 悪い要求

   The request could not be understood due to malformed syntax.  The
   Reason-Phrase SHOULD identify the syntax problem in more detail, for
   example, "Missing Call-ID header field".

奇形の構文のため要求を理解できませんでした。 「Call-IDヘッダーフィールドを逃し」て、Reason-句のSHOULDはさらに詳細に、例えば構文問題を特定します。

21.4.2 401 Unauthorized

21.4.2 401 権限がありません。

   The request requires user authentication.  This response is issued by
   UASs and registrars, while 407 (Proxy Authentication Required) is
   used by proxy servers.

要求はユーザー認証を必要とします。 この応答はUASsと記録係によって発行されますが、407(プロキシAuthentication Required)は代理人を通して使用されます。サーバ。

Rosenberg, et. al.          Standards Track                   [Page 185]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[185ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

21.4.3 402 Payment Required

21.4.3 402 支払いが必要です。

   Reserved for future use.

今後の使用のために、予約されます。

21.4.4 403 Forbidden

21.4.4 403 禁制です。

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help, and the request SHOULD NOT be repeated.

サーバは、要求を理解していますが、それを実現させるのを拒否しています。 承認は助けでなく、および要求SHOULD NOTを望んでいます。繰り返されます。

21.4.5 404 Not Found

21.4.5 404 見つけられませんでした。

   The server has definitive information that the user does not exist at
   the domain specified in the Request-URI.  This status is also
   returned if the domain in the Request-URI does not match any of the
   domains handled by the recipient of the request.

サーバには、ユーザがRequest-URIで指定されたドメインに存在しないという決定的な情報があります。 また、Request-URIにおけるドメインが要求の受取人によって扱われたドメインのいずれにも合っていないなら、この状態は返されます。

21.4.6 405 Method Not Allowed

21.4.6 405 許容されなかったメソッド

   The method specified in the Request-Line is understood, but not
   allowed for the address identified by the Request-URI.

Request-線で指定されたメソッドは、理解されていますが、Request-URIによって特定されたアドレスのために許容されていません。

   The response MUST include an Allow header field containing a list of
   valid methods for the indicated address.

応答は示されたアドレスのための有効なメソッドのリストを含むAllowヘッダーフィールドを含まなければなりません。

21.4.7 406 Not Acceptable

21.4.7 406 許容できません。

   The resource identified by the request is only capable of generating
   response entities that have content characteristics not acceptable
   according to the Accept header field sent in the request.

要求で特定されたリソースは要求で送られたAcceptヘッダーフィールドに従って許容できない特性を内容を持っている応答実体に生成することができるだけです。

21.4.8 407 Proxy Authentication Required

21.4.8 407 プロキシ認証が必要です。

   This code is similar to 401 (Unauthorized), but indicates that the
   client MUST first authenticate itself with the proxy.  SIP access
   authentication is explained in Sections 26 and 22.3.

このコードは、401と同様ですが(権限のない)、クライアントが最初にプロキシと共にそれ自体を認証しなければならないのを示します。 SIPアクセス認証はセクション26と22.3で説明されます。

   This status code can be used for applications where access to the
   communication channel (for example, a telephony gateway) rather than
   the callee requires authentication.

訪問される人よりむしろ通信チャネル(例えば、電話ゲートウェイ)へのアクセスが認証を必要とするアプリケーションにこのステータスコードを使用できます。

21.4.9 408 Request Timeout

21.4.9 408 タイムアウトを要求してください。

   The server could not produce a response within a suitable amount of
   time, for example, if it could not determine the location of the user
   in time.  The client MAY repeat the request without modifications at
   any later time.

例えば、時間内にユーザの位置を決定できないなら、サーバは適当な時間以内に応答を起こすことができないでしょうに。 クライアントは後の何時でも変更なしで要求を繰り返すかもしれません。

Rosenberg, et. al.          Standards Track                   [Page 186]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[186ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

21.4.10 410 Gone

21.4.10 410 過ぎ去ります。

   The requested resource is no longer available at the server and no
   forwarding address is known.  This condition is expected to be
   considered permanent.  If the server does not know, or has no
   facility to determine, whether or not the condition is permanent, the
   status code 404 (Not Found) SHOULD be used instead.

要求されたリソースはもうサーバで利用可能ではありません、そして、フォーワーディング・アドレスは全く知られていません。 永久的であるとこの状態が考えられると予想されます。 サーバに、知らないか、または状態が永久的であるか否かに関係なく、ステータスコード404(Foundでない)SHOULDが代わりに使用されることを決定する施設が全くないなら。

21.4.11 413 Request Entity Too Large

21.4.11 413 大き過ぎる状態で実体を要求してください。

   The server is refusing to process a request because the request
   entity-body is larger than the server is willing or able to process.
   The server MAY close the connection to prevent the client from
   continuing the request.

サーバは、要求実体本体がサーバが望んでいるか、または処理できるより大きいので要求を処理するのを拒否しています。 サーバは、クライアントが要求を続けているのを防ぐために接続を終えるかもしれません。

   If the condition is temporary, the server SHOULD include a Retry-
   After header field to indicate that it is temporary and after what
   time the client MAY try again.

状態が一時的であるなら、サーバSHOULDは、ヘッダーフィールドの後にそれが一時的であることを示して、クライアントが再試行するかもしれない何時の後に含むようにRetryを含んでいるか。

21.4.12 414 Request-URI Too Long

21.4.12 414 要求URIも長さ

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret.

サーバは、サーバが、解釈しても構わないと思っているよりRequest-URIが長いので要求を修理するのを拒否しています。

21.4.13 415 Unsupported Media Type

21.4.13 415 サポートされないメディアタイプ

   The server is refusing to service the request because the message
   body of the request is in a format not supported by the server for
   the requested method.  The server MUST return a list of acceptable
   formats using the Accept, Accept-Encoding, or Accept-Language header
   field, depending on the specific problem with the content.  UAC
   processing of this response is described in Section 8.1.3.5.

サーバは、要求されたメソッドのためにサーバによってサポートされなかった形式には要求のメッセージ本体があるので要求を修理するのを拒否しています。 Accept、Accept-コード化、またはAccept-言語ヘッダーフィールドを使用して、サーバは許容形式のリストを返さなければなりません、内容に関する特定の問題によって。 この応答のUAC処理はセクション8.1.3で.5に説明されます。

21.4.14 416 Unsupported URI Scheme

21.4.14 416 サポートされないURI体系

   The server cannot process the request because the scheme of the URI
   in the Request-URI is unknown to the server.  Client processing of
   this response is described in Section 8.1.3.5.

サーバにおいて、Request-URIにおけるURIの体系が未知であるので、サーバは要求を処理できません。この応答のクライアント処理はセクション8.1.3で.5に説明されます。

21.4.15 420 Bad Extension

21.4.15 420 悪い拡大

   The server did not understand the protocol extension specified in a
   Proxy-Require (Section 20.29) or Require (Section 20.32) header
   field.  The server MUST include a list of the unsupported extensions
   in an Unsupported header field in the response.  UAC processing of
   this response is described in Section 8.1.3.5.

サーバは、aで指定されたプロトコル拡張子が(セクション20.29)かRequire(セクション20.32)ヘッダーフィールドをProxy必要とするのを理解していませんでした。 サーバはUnsupportedヘッダーフィールドに応答でサポートされない拡大のリストを含まなければなりません。 この応答のUAC処理はセクション8.1.3で.5に説明されます。

Rosenberg, et. al.          Standards Track                   [Page 187]

RFC 3261            SIP: Session Initiation Protocol           June 2002

etローゼンバーグ、アル。 標準化過程[187ページ]RFC3261はちびちび飲みます: セッション開始プロトコル2002年6月

21.4.16 421 Extension Required

21.4.16 421 拡大が必要です。

   The UAS needs a particular extension to process the request, but this
   extension is not listed in a Supported header field in the request.
   Responses with this status code MUST contain a Require header field
   listing the required extensions.

UASは要求を処理するために特定の拡大を必要としますが、この拡大は要求におけるSupportedヘッダーフィールドでは記載されていません。 このステータスコードによる応答は必要な拡大を記載するRequireヘッダーフィールドを含まなければなりません。

   A UAS SHOULD NOT use this response unless it truly cannot provide any
   useful service to the client.  Instead, if a desirable extension is
   not listed in the Supported header field, servers SHOULD process the
   request using baseline SIP capabilities and any extensions supported
   by the client.

本当にクライアントに対するどんな役に立つサービスも提供できるなら、UAS SHOULD NOTはこの応答を使用します。 代わりに、望ましい拡大がSupportedヘッダーフィールドで記載されないなら、サーバSHOULDは、基線SIP能力とクライアントによってサポートされたどんな拡張子も使用することで要求を処理します。

21.4.17 423 Interval Too Brief

21.4.17 423 間隔も事情を知らせます。

   The server is rejecting the request because the expiration time of
   the resource refreshed by the request is too short.  This response
   can be used by a registrar to reject a registration whose Contact
   header field expiration time was too small.  The use of this response
   and the related Min-Expires header field are described in Sections
   10.2.8, 10.3, and 20.23.

要求でリフレッシュされたリソースの満了間が短過ぎるので、サーバは要求を拒絶しています。 記録係は、Contactヘッダーフィールド満了時間が小さ過ぎた登録を拒絶するのにこの応答を使用できます。 この応答の使用と関連はヘッダーフィールドをMin吐き出します。セクション10.2.8、10.3、および20.23では、説明されます。

21.4.18 480 Temporarily Unavailable

21.4.18 480 一時入手できません。

   The callee's end system was contacted successfully but the callee is
   currently unavailable (for example, is not logged in, logged in but
   in a state that precludes communication with the callee, or has
   activated the "do not disturb" feature).  The response MAY indicate a
   better time to call in the Retry-After header field.  The user could
   also be available elsewhere (unbeknownst to this server).  The reason
   phrase SHOULD indicate a more precise cause as to why the callee is
   unavailable.  This value SHOULD be settable by the UA.  Status 486
   (Busy Here) MAY be used to more precisely indicate a particular
   reason for the call failure.

訪問される人のエンドシステムは首尾よく連絡されましたが、訪問される人は現在、入手できません(例えば、ログインされないで、状態にもかかわらず、状態に登録されて、それは、訪問される人とのコミュニケーションを排除するか、または「擾乱しないでください」という特徴を活性化しました)。 応答は後のRetryヘッダーフィールドを回収するより良い時間を示すかもしれません。 また、ユーザもほかの場所で入手できるかもしれません(このサーバに知られずに)。 理由句のSHOULDは訪問される人が入手できない理由に関して、より正確な原因を示します。 これはSHOULDを評価します。UAで、「舗装用敷石-可能」であってください。 状態486(忙しいHere)は、より正確に呼び出し失敗の特定の理由を示すのに使用されるかもしれません。

   This status is also returned by a redirect or proxy server that
   recognizes the user identified by the Request-URI, but does not
   currently have a valid forwarding location for that user.

また、この状態がaによって再直接で返されるか、ユーザを見分けるプロキシサーバが、Request-URIを特定しますが、現在、そのユーザにとって、有効な推進位置を持っていません。

21.4.19 481 Call/Transaction Does Not Exist

21.4.19 481 呼び出し/トランザクションは存在していません。

   This status indicates that the UAS received a request that does not
   match any existing dialog or transaction.

この状態は、UASがどんな既存の対話やトランザクションにも合っていない要求を受け取ったのを示します。

21.4.20 482 Loop Detected

21.4.20 482 検出された輪

   The server has detected a loop (Section 16.3 Item 4).

The server has detected a loop (Section 16.3 Item 4).

Rosenberg, et. al.          Standards Track                   [Page 188]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 188] RFC 3261 SIP: Session Initiation Protocol June 2002

21.4.21 483 Too Many Hops

21.4.21 483 Too Many Hops

   The server received a request that contains a Max-Forwards (Section
   20.22) header field with the value zero.

The server received a request that contains a Max-Forwards (Section 20.22) header field with the value zero.

21.4.22 484 Address Incomplete

21.4.22 484 Address Incomplete

   The server received a request with a Request-URI that was incomplete.
   Additional information SHOULD be provided in the reason phrase.

The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase.

      This status code allows overlapped dialing.  With overlapped
      dialing, the client does not know the length of the dialing
      string.  It sends strings of increasing lengths, prompting the
      user for more input, until it no longer receives a 484 (Address
      Incomplete) status response.

This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response.

21.4.23 485 Ambiguous

21.4.23 485 Ambiguous

   The Request-URI was ambiguous.  The response MAY contain a listing of
   possible unambiguous addresses in Contact header fields.  Revealing
   alternatives can infringe on privacy of the user or the organization.
   It MUST be possible to configure a server to respond with status 404
   (Not Found) or to suppress the listing of possible choices for
   ambiguous Request-URIs.

The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs.

   Example response to a request with the Request-URI
   sip:lee@example.com:

Example response to a request with the Request-URI sip:lee@example.com:

      SIP/2.0 485 Ambiguous
      Contact: Carol Lee <sip:carol.lee@example.com>
      Contact: Ping Lee <sip:p.lee@example.com>
      Contact: Lee M. Foote <sips:lee.foote@example.com>

SIP/2.0 485 Ambiguous Contact: Carol Lee <sip:carol.lee@example.com> Contact: Ping Lee <sip:p.lee@example.com> Contact: Lee M. Foote <sips:lee.foote@example.com>

      Some email and voice mail systems provide this functionality.  A
      status code separate from 3xx is used since the semantics are
      different: for 300, it is assumed that the same person or service
      will be reached by the choices provided.  While an automated
      choice or sequential search makes sense for a 3xx response, user
      intervention is required for a 485 (Ambiguous) response.

Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response.

21.4.24 486 Busy Here

21.4.24 486 Busy Here

   The callee's end system was contacted successfully, but the callee is
   currently not willing or able to take additional calls at this end
   system.  The response MAY indicate a better time to call in the
   Retry-After header field.  The user could also be available

The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available

Rosenberg, et. al.          Standards Track                   [Page 189]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 189] RFC 3261 SIP: Session Initiation Protocol June 2002

   elsewhere, such as through a voice mail service.  Status 600 (Busy
   Everywhere) SHOULD be used if the client knows that no other end
   system will be able to accept this call.

elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call.

21.4.25 487 Request Terminated

21.4.25 487 Request Terminated

   The request was terminated by a BYE or CANCEL request.  This response
   is never returned for a CANCEL request itself.

The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself.

21.4.26 488 Not Acceptable Here

21.4.26 488 Not Acceptable Here

   The response has the same meaning as 606 (Not Acceptable), but only
   applies to the specific resource addressed by the Request-URI and the
   request may succeed elsewhere.

The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.

   A message body containing a description of media capabilities MAY be
   present in the response, which is formatted according to the Accept
   header field in the INVITE (or application/sdp if not present), the
   same as a message body in a 200 (OK) response to an OPTIONS request.

A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.

21.4.27 491 Request Pending

21.4.27 491 Request Pending

   The request was received by a UAS that had a pending request within
   the same dialog.  Section 14.2 describes how such "glare" situations
   are resolved.

The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such "glare" situations are resolved.

21.4.28 493 Undecipherable

21.4.28 493 Undecipherable

   The request was received by a UAS that contained an encrypted MIME
   body for which the recipient does not possess or will not provide an
   appropriate decryption key.  This response MAY have a single body
   containing an appropriate public key that should be used to encrypt
   MIME bodies sent to this UA.  Details of the usage of this response
   code can be found in Section 23.2.

The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. Details of the usage of this response code can be found in Section 23.2.

21.5 Server Failure 5xx

21.5 Server Failure 5xx

   5xx responses are failure responses given when a server itself has
   erred.

5xx responses are failure responses given when a server itself has erred.

21.5.1 500 Server Internal Error

21.5.1 500 Server Internal Error

   The server encountered an unexpected condition that prevented it from
   fulfilling the request.  The client MAY display the specific error
   condition and MAY retry the request after several seconds.

The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds.

   If the condition is temporary, the server MAY indicate when the
   client may retry the request using the Retry-After header field.

If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field.

Rosenberg, et. al.          Standards Track                   [Page 190]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 190] RFC 3261 SIP: Session Initiation Protocol June 2002

21.5.2 501 Not Implemented

21.5.2 501 Not Implemented

   The server does not support the functionality required to fulfill the
   request.  This is the appropriate response when a UAS does not
   recognize the request method and is not capable of supporting it for
   any user.  (Proxies forward all requests regardless of method.)

The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.)

   Note that a 405 (Method Not Allowed) is sent when the server
   recognizes the request method, but that method is not allowed or
   supported.

Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported.

21.5.3 502 Bad Gateway

21.5.3 502 Bad Gateway

   The server, while acting as a gateway or proxy, received an invalid
   response from the downstream server it accessed in attempting to
   fulfill the request.

The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request.

21.5.4 503 Service Unavailable

21.5.4 503 Service Unavailable

   The server is temporarily unable to process the request due to a
   temporary overloading or maintenance of the server.  The server MAY
   indicate when the client should retry the request in a Retry-After
   header field.  If no Retry-After is given, the client MUST act as if
   it had received a 500 (Server Internal Error) response.

The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.

   A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   attempt to forward the request to an alternate server.  It SHOULD NOT
   forward any other requests to that server for the duration specified
   in the Retry-After header field, if present.

A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.

   Servers MAY refuse the connection or drop the request instead of
   responding with 503 (Service Unavailable).

Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).

21.5.5 504 Server Time-out

21.5.5 504 Server Time-out

   The server did not receive a timely response from an external server
   it accessed in attempting to process the request.  408 (Request
   Timeout) should be used instead if there was no response within the
   period specified in the Expires header field from the upstream
   server.

The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server.

21.5.6 505 Version Not Supported

21.5.6 505 Version Not Supported

   The server does not support, or refuses to support, the SIP protocol
   version that was used in the request.  The server is indicating that
   it is unable or unwilling to complete the request using the same
   major version as the client, other than with this error message.

The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message.

Rosenberg, et. al.          Standards Track                   [Page 191]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 191] RFC 3261 SIP: Session Initiation Protocol June 2002

21.5.7 513 Message Too Large

21.5.7 513 Message Too Large

   The server was unable to process the request since the message length
   exceeded its capabilities.

The server was unable to process the request since the message length exceeded its capabilities.

21.6 Global Failures 6xx

21.6 Global Failures 6xx

   6xx responses indicate that a server has definitive information about
   a particular user, not just the particular instance indicated in the
   Request-URI.

6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.

21.6.1 600 Busy Everywhere

21.6.1 600 Busy Everywhere

   The callee's end system was contacted successfully but the callee is
   busy and does not wish to take the call at this time.  The response
   MAY indicate a better time to call in the Retry-After header field.
   If the callee does not wish to reveal the reason for declining the
   call, the callee uses status code 603 (Decline) instead.  This status
   response is returned only if the client knows that no other end point
   (such as a voice mail system) will answer the request.  Otherwise,
   486 (Busy Here) should be returned.

The callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field. If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned.

21.6.2 603 Decline

21.6.2 603 Decline

   The callee's machine was successfully contacted but the user
   explicitly does not wish to or cannot participate.  The response MAY
   indicate a better time to call in the Retry-After header field.  This
   status response is returned only if the client knows that no other
   end point will answer the request.

The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request.

21.6.3 604 Does Not Exist Anywhere

21.6.3 604 Does Not Exist Anywhere

   The server has authoritative information that the user indicated in
   the Request-URI does not exist anywhere.

The server has authoritative information that the user indicated in the Request-URI does not exist anywhere.

21.6.4 606 Not Acceptable

21.6.4 606 Not Acceptable

   The user's agent was contacted successfully but some aspects of the
   session description such as the requested media, bandwidth, or
   addressing style were not acceptable.

The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.

   A 606 (Not Acceptable) response means that the user wishes to
   communicate, but cannot adequately support the session described.
   The 606 (Not Acceptable) response MAY contain a list of reasons in a
   Warning header field describing why the session described cannot be
   supported.  Warning reason codes are listed in Section 20.43.

A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43.

Rosenberg, et. al.          Standards Track                   [Page 192]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 192] RFC 3261 SIP: Session Initiation Protocol June 2002

   A message body containing a description of media capabilities MAY be
   present in the response, which is formatted according to the Accept
   header field in the INVITE (or application/sdp if not present), the
   same as a message body in a 200 (OK) response to an OPTIONS request.

A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.

   It is hoped that negotiation will not frequently be needed, and when
   a new user is being invited to join an already existing conference,
   negotiation may not be possible.  It is up to the invitation
   initiator to decide whether or not to act on a 606 (Not Acceptable)
   response.

It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response.

   This status response is returned only if the client knows that no
   other end point will answer the request.

This status response is returned only if the client knows that no other end point will answer the request.

22 Usage of HTTP Authentication

22 Usage of HTTP Authentication

   SIP provides a stateless, challenge-based mechanism for
   authentication that is based on authentication in HTTP.  Any time
   that a proxy server or UA receives a request (with the exceptions
   given in Section 22.1), it MAY challenge the initiator of the request
   to provide assurance of its identity.  Once the originator has been
   identified, the recipient of the request SHOULD ascertain whether or
   not this user is authorized to make the request in question.  No
   authorization systems are recommended or discussed in this document.

SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document.

   The "Digest" authentication mechanism described in this section
   provides message authentication and replay protection only, without
   message integrity or confidentiality.  Protective measures above and
   beyond those provided by Digest need to be taken to prevent active
   attackers from modifying SIP requests and responses.

The "Digest" authentication mechanism described in this section provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and responses.

   Note that due to its weak security, the usage of "Basic"
   authentication has been deprecated.  Servers MUST NOT accept
   credentials using the "Basic" authorization scheme, and servers also
   MUST NOT challenge with "Basic".  This is a change from RFC 2543.

Note that due to its weak security, the usage of "Basic" authentication has been deprecated. Servers MUST NOT accept credentials using the "Basic" authorization scheme, and servers also MUST NOT challenge with "Basic". This is a change from RFC 2543.

22.1 Framework

22.1 Framework

   The framework for SIP authentication closely parallels that of HTTP
   (RFC 2617 [17]).  In particular, the BNF for auth-scheme, auth-param,
   challenge, realm, realm-value, and credentials is identical (although
   the usage of "Basic" as a scheme is not permitted).  In SIP, a UAS
   uses the 401 (Unauthorized) response to challenge the identity of a
   UAC.  Additionally, registrars and redirect servers MAY make use of
   401 (Unauthorized) responses for authentication, but proxies MUST
   NOT, and instead MAY use the 407 (Proxy Authentication Required)

The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical (although the usage of "Basic" as a scheme is not permitted). In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required)

Rosenberg, et. al.          Standards Track                   [Page 193]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 193] RFC 3261 SIP: Session Initiation Protocol June 2002

   response.  The requirements for inclusion of the Proxy-Authenticate,
   Proxy-Authorization, WWW-Authenticate, and Authorization in the
   various messages are identical to those described in RFC 2617 [17].

response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to those described in RFC 2617 [17].

   Since SIP does not have the concept of a canonical root URL, the
   notion of protection spaces is interpreted differently in SIP.  The
   realm string alone defines the protection domain.  This is a change
   from RFC 2543, in which the Request-URI and the realm together
   defined the protection domain.

Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is interpreted differently in SIP. The realm string alone defines the protection domain. This is a change from RFC 2543, in which the Request-URI and the realm together defined the protection domain.

      This previous definition of protection domain caused some amount
      of confusion since the Request-URI sent by the UAC and the
      Request-URI received by the challenging server might be different,
      and indeed the final form of the Request-URI might not be known to
      the UAC.  Also, the previous definition depended on the presence
      of a SIP URI in the Request-URI and seemed to rule out alternative
      URI schemes (for example, the tel URL).

This previous definition of protection domain caused some amount of confusion since the Request-URI sent by the UAC and the Request-URI received by the challenging server might be different, and indeed the final form of the Request-URI might not be known to the UAC. Also, the previous definition depended on the presence of a SIP URI in the Request-URI and seemed to rule out alternative URI schemes (for example, the tel URL).

   Operators of user agents or proxy servers that will authenticate
   received requests MUST adhere to the following guidelines for
   creation of a realm string for their server:

Operators of user agents or proxy servers that will authenticate received requests MUST adhere to the following guidelines for creation of a realm string for their server:

      o  Realm strings MUST be globally unique.  It is RECOMMENDED that
         a realm string contain a hostname or domain name, following the
         recommendation in Section 3.2.1 of RFC 2617 [17].

o Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17].

      o  Realm strings SHOULD present a human-readable identifier that
         can be rendered to a user.

o Realm strings SHOULD present a human-readable identifier that can be rendered to a user.

   For example:

For example:

      INVITE sip:bob@biloxi.com SIP/2.0
      Authorization: Digest realm="biloxi.com", <...>

INVITE sip:bob@biloxi.com SIP/2.0 Authorization: Digest realm="biloxi.com", <...>

   Generally, SIP authentication is meaningful for a specific realm, a
   protection domain.  Thus, for Digest authentication, each such
   protection domain has its own set of usernames and passwords.  If a
   server does not require authentication for a particular request, it
   MAY accept a default username, "anonymous", which has no password
   (password of "").  Similarly, UACs representing many users, such as
   PSTN gateways, MAY have their own device-specific username and
   password, rather than accounts for particular users, for their realm.

Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest authentication, each such protection domain has its own set of usernames and passwords. If a server does not require authentication for a particular request, it MAY accept a default username, "anonymous", which has no password (password of ""). Similarly, UACs representing many users, such as PSTN gateways, MAY have their own device-specific username and password, rather than accounts for particular users, for their realm.

   While a server can legitimately challenge most SIP requests, there
   are two requests defined by this document that require special
   handling for authentication: ACK and CANCEL.

While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL.

Rosenberg, et. al.          Standards Track                   [Page 194]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 194] RFC 3261 SIP: Session Initiation Protocol June 2002

   Under an authentication scheme that uses responses to carry values
   used to compute nonces (such as Digest), some problems come up for
   any requests that take no response, including ACK.  For this reason,
   any credentials in the INVITE that were accepted by a server MUST be
   accepted by that server for the ACK.  UACs creating an ACK message
   will duplicate all of the Authorization and Proxy-Authorization
   header field values that appeared in the INVITE to which the ACK
   corresponds.  Servers MUST NOT attempt to challenge an ACK.

Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK.

   Although the CANCEL method does take a response (a 2xx), servers MUST
   NOT attempt to challenge CANCEL requests since these requests cannot
   be resubmitted.  Generally, a CANCEL request SHOULD be accepted by a
   server if it comes from the same hop that sent the request being
   canceled (provided that some sort of transport or network layer
   security association, as described in Section 26.2.1, is in place).

Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place).

   When a UAC receives a challenge, it SHOULD render to the user the
   contents of the "realm" parameter in the challenge (which appears in
   either a WWW-Authenticate header field or Proxy-Authenticate header
   field) if the UAC device does not already know of a credential for
   the realm in question.  A service provider that pre-configures UAs
   with credentials for its realm should be aware that users will not
   have the opportunity to present their own credentials for this realm
   when challenged at a pre-configured device.

When a UAC receives a challenge, it SHOULD render to the user the contents of the "realm" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question. A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device.

   Finally, note that even if a UAC can locate credentials that are
   associated with the proper realm, the potential exists that these
   credentials may no longer be valid or that the challenging server
   will not accept these credentials for whatever reason (especially
   when "anonymous" with no password is submitted).  In this instance a
   server may repeat its challenge, or it may respond with a 403
   Forbidden.  A UAC MUST NOT re-attempt requests with the credentials
   that have just been rejected (though the request may be retried if
   the nonce was stale).

Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the potential exists that these credentials may no longer be valid or that the challenging server will not accept these credentials for whatever reason (especially when "anonymous" with no password is submitted). In this instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale).

22.2 User-to-User Authentication

22.2 User-to-User Authentication

   When a UAS receives a request from a UAC, the UAS MAY authenticate
   the originator before the request is processed.  If no credentials
   (in the Authorization header field) are provided in the request, the
   UAS can challenge the originator to provide credentials by rejecting
   the request with a 401 (Unauthorized) status code.

When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code.

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages.  The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the realm.

The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm.

Rosenberg, et. al.          Standards Track                   [Page 195]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 195] RFC 3261 SIP: Session Initiation Protocol June 2002

   An example of the WWW-Authenticate header field in a 401 challenge
   is:

An example of the WWW-Authenticate header field in a 401 challenge is:

      WWW-Authenticate: Digest
              realm="biloxi.com",
              qop="auth,auth-int",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"

   When the originating UAC receives the 401 (Unauthorized), it SHOULD,
   if it is able, re-originate the request with the proper credentials.
   The UAC may require input from the originating user before
   proceeding.  Once authentication credentials have been supplied
   (either directly by the user, or discovered in an internal keyring),
   UAs SHOULD cache the credentials for a given value of the To header
   field and "realm" and attempt to re-use these values on the next
   request for that destination.  UAs MAY cache credentials in any way
   they would like.

When the originating UAC receives the 401 (Unauthorized), it SHOULD, if it is able, re-originate the request with the proper credentials. The UAC may require input from the originating user before proceeding. Once authentication credentials have been supplied (either directly by the user, or discovered in an internal keyring), UAs SHOULD cache the credentials for a given value of the To header field and "realm" and attempt to re-use these values on the next request for that destination. UAs MAY cache credentials in any way they would like.

   If no credentials for a realm can be located, UACs MAY attempt to
   retry the request with a username of "anonymous" and no password (a
   password of "").

If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of "anonymous" and no password (a password of "").

   Once credentials have been located, any UA that wishes to
   authenticate itself with a UAS or registrar -- usually, but not
   necessarily, after receiving a 401 (Unauthorized) response -- MAY do
   so by including an Authorization header field with the request.  The
   Authorization field value consists of credentials containing the
   authentication information of the UA for the realm of the resource
   being requested as well as parameters required in support of
   authentication and replay protection.

Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response -- MAY do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the UA for the realm of the resource being requested as well as parameters required in support of authentication and replay protection.

   An example of the Authorization header field is:

An example of the Authorization header field is:

      Authorization: Digest username="bob",
              realm="biloxi.com",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              uri="sip:bob@biloxi.com",
              qop=auth,
              nc=00000001,
              cnonce="0a4f113b",
              response="6629fae49393a05397450978507c4ef1",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

   When a UAC resubmits a request with its credentials after receiving a
   401 (Unauthorized) or 407 (Proxy Authentication Required) response,
   it MUST increment the CSeq header field value as it would normally
   when sending an updated request.

When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request.

Rosenberg, et. al.          Standards Track                   [Page 196]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 196] RFC 3261 SIP: Session Initiation Protocol June 2002

22.3 Proxy-to-User Authentication

22.3 Proxy-to-User Authentication

   Similarly, when a UAC sends a request to a proxy server, the proxy
   server MAY authenticate the originator before the request is
   processed.  If no credentials (in the Proxy-Authorization header
   field) are provided in the request, the proxy can challenge the
   originator to provide credentials by rejecting the request with a 407
   (Proxy Authentication Required) status code.  The proxy MUST populate
   the 407 (Proxy Authentication Required) message with a Proxy-
   Authenticate header field value applicable to the proxy for the
   requested resource.

Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed. If no credentials (in the Proxy-Authorization header field) are provided in the request, the proxy can challenge the originator to provide credentials by rejecting the request with a 407 (Proxy Authentication Required) status code. The proxy MUST populate the 407 (Proxy Authentication Required) message with a Proxy- Authenticate header field value applicable to the proxy for the requested resource.

   The use of Proxy-Authenticate and Proxy-Authorization parallel that
   described in [17], with one difference.  Proxies MUST NOT add values
   to the Proxy-Authorization header field.  All 407 (Proxy
   Authentication Required) responses MUST be forwarded upstream toward
   the UAC following the procedures for any other response.  It is the
   UAC's responsibility to add the Proxy-Authorization header field
   value containing credentials for the realm of the proxy that has
   asked for authentication.

The use of Proxy-Authenticate and Proxy-Authorization parallel that described in [17], with one difference. Proxies MUST NOT add values to the Proxy-Authorization header field. All 407 (Proxy Authentication Required) responses MUST be forwarded upstream toward the UAC following the procedures for any other response. It is the UAC's responsibility to add the Proxy-Authorization header field value containing credentials for the realm of the proxy that has asked for authentication.

      If a proxy were to resubmit a request adding a Proxy-Authorization
      header field value, it would need to increment the CSeq in the new
      request.  However, this would cause the UAC that submitted the
      original request to discard a response from the UAS, as the CSeq
      value would be different.

If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different.

   When the originating UAC receives the 407 (Proxy Authentication
   Required) it SHOULD, if it is able, re-originate the request with the
   proper credentials.  It should follow the same procedures for the
   display of the "realm" parameter that are given above for responding
   to 401.

When the originating UAC receives the 407 (Proxy Authentication Required) it SHOULD, if it is able, re-originate the request with the proper credentials. It should follow the same procedures for the display of the "realm" parameter that are given above for responding to 401.

   If no credentials for a realm can be located, UACs MAY attempt to
   retry the request with a username of "anonymous" and no password (a
   password of "").

If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of "anonymous" and no password (a password of "").

   The UAC SHOULD also cache the credentials used in the re-originated
   request.

The UAC SHOULD also cache the credentials used in the re-originated request.

   The following rule is RECOMMENDED for proxy credential caching:

The following rule is RECOMMENDED for proxy credential caching:

   If a UA receives a Proxy-Authenticate header field value in a 401/407
   response to a request with a particular Call-ID, it should
   incorporate credentials for that realm in all subsequent requests
   that contain the same Call-ID.  These credentials MUST NOT be cached
   across dialogs; however, if a UA is configured with the realm of its
   local outbound proxy, when one exists, then the UA MAY cache

If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a particular Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the same Call-ID. These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache

Rosenberg, et. al.          Standards Track                   [Page 197]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 197] RFC 3261 SIP: Session Initiation Protocol June 2002

   credentials for that realm across dialogs.  Note that this does mean
   a future request in a dialog could contain credentials that are not
   needed by any proxy along the Route header path.

credentials for that realm across dialogs. Note that this does mean a future request in a dialog could contain credentials that are not needed by any proxy along the Route header path.

   Any UA that wishes to authenticate itself to a proxy server --
   usually, but not necessarily, after receiving a 407 (Proxy
   Authentication Required) response -- MAY do so by including a Proxy-
   Authorization header field value with the request.  The Proxy-
   Authorization request-header field allows the client to identify
   itself (or its user) to a proxy that requires authentication.  The
   Proxy-Authorization header field value consists of credentials
   containing the authentication information of the UA for the proxy
   and/or realm of the resource being requested.

Any UA that wishes to authenticate itself to a proxy server -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) response -- MAY do so by including a Proxy- Authorization header field value with the request. The Proxy- Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization header field value consists of credentials containing the authentication information of the UA for the proxy and/or realm of the resource being requested.

   A Proxy-Authorization header field value applies only to the proxy
   whose realm is identified in the "realm" parameter (this proxy may
   previously have demanded authentication using the Proxy-Authenticate
   field).  When multiple proxies are used in a chain, a Proxy-
   Authorization header field value MUST NOT be consumed by any proxy
   whose realm does not match the "realm" parameter specified in that
   value.

A Proxy-Authorization header field value applies only to the proxy whose realm is identified in the "realm" parameter (this proxy may previously have demanded authentication using the Proxy-Authenticate field). When multiple proxies are used in a chain, a Proxy- Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the "realm" parameter specified in that value.

   Note that if an authentication scheme that does not support realms is
   used in the Proxy-Authorization header field, a proxy server MUST
   attempt to parse all Proxy-Authorization header field values to
   determine whether one of them has what the proxy server considers to
   be valid credentials.  Because this is potentially very time-
   consuming in large networks, proxy servers SHOULD use an
   authentication scheme that supports realms in the Proxy-Authorization
   header field.

Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization header field, a proxy server MUST attempt to parse all Proxy-Authorization header field values to determine whether one of them has what the proxy server considers to be valid credentials. Because this is potentially very time- consuming in large networks, proxy servers SHOULD use an authentication scheme that supports realms in the Proxy-Authorization header field.

   If a request is forked (as described in Section 16.7), various proxy
   servers and/or UAs may wish to challenge the UAC.  In this case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.

If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant.

      When a proxy server issues a challenge in response to a request,
      it will not proxy the request until the UAC has retried the
      request with valid credentials.  A forking proxy may forward a
      request simultaneously to multiple proxy servers that require
      authentication, each of which in turn will not forward the request
      until the originating UAC has authenticated itself in their
      respective realm.  If the UAC does not provide credentials for

When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy servers that require authentication, each of which in turn will not forward the request until the originating UAC has authenticated itself in their respective realm. If the UAC does not provide credentials for

Rosenberg, et. al.          Standards Track                   [Page 198]

RFC 3261            SIP: Session Initiation Protocol           June 2002

Rosenberg, et. al. Standards Track [Page 198] RFC 3261 SIP: Session Initiation Protocol June 2002

一覧

 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 

スポンサーリンク

ペンギンの平均寿命

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る