Network Working Group M. Handley
Request for Comments: 2543 ACIRI
Category: Standards Track H. Schulzrinne
Columbia U.
E. Schooler
Cal Tech
J. Rosenberg
Bell Labs
March 1999
SIP: Session Initiation Protocol
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
IESG Note
IESG注意
The IESG intends to charter, in the near future, one or more working groups to produce standards for "name lookup", where such names would include electronic mail addresses and telephone numbers, and the result of such a lookup would be a list of attributes and characteristics of the user or terminal associated with the name. Groups which are in need of a "name lookup" protocol should follow the development of these new working groups rather than using SIP for this function. In addition it is anticipated that SIP will migrate towards using such protocols, and SIP implementors are advised to monitor these efforts.
IESGは、このような名前は、電子メールアドレスや電話番号が含まれるであろう近い将来、「名前検索」の基準を生成するための1つ以上のワーキンググループで、チャーターしていき、そして、そのような検索の結果は、属性のリストになりますそして名前に関連付けられたユーザまたは端末の特性。 「名前検索」プロトコルを必要としているグループではなく、この機能のためにSIPを使用するよりも、これらの新しいワーキンググループの発展に従ってください。それに加えて、SIPは、そのようなプロトコルを使用してに向かって移動することが予想され、SIPの実装者は、これらの取り組みを監視することをお勧めします。
Abstract
抽象
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
セッション開始プロトコル（SIP）は、1つ以上の参加者とのセッションを作成、修正、および終了するためのアプリケーション層制御（シグナリング）プロトコルです。これらのセッションは、インターネットマルチメディア会議、インターネット電話やマルチメディア配信が含まれます。セッション内のメンバーは、マルチキャストを介して、またはユニキャスト関係のメッシュ、またはこれらの組み合わせを介して通信することができます。
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.
セッションを作成するために使用されるSIP招待状は、参加者が互換性のあるメディアタイプのセットに同意することを可能にするセッション記述を運びます。 SIPは、ユーザの現在の場所へのリクエストをプロキシとリダイレクトすることで、ユーザのモビリティをサポートしています。ユーザーは、自分の現在位置を登録することができます。 SIPは、任意の特定の会議制御プロトコルに縛られていません。 SIPは、下層のトランスポートプロトコルに依存しないように設計されており、追加機能で拡張することができます。
Table of Contents
目次
1 Introduction ........................................ 7
1.1 Overview of SIP Functionality ....................... 7
1.2 Terminology ......................................... 8
1.3 Definitions ......................................... 9
1.4 Overview of SIP Operation ........................... 12
1.4.1 SIP Addressing ...................................... 12
1.4.2 Locating a SIP Server ............................... 13
1.4.3 SIP Transaction ..................................... 14
1.4.4 SIP Invitation ...................................... 15
1.4.5 Locating a User ..................................... 17
1.4.6 Changing an Existing Session ........................ 18
1.4.7 Registration Services ............................... 18
1.5 Protocol Properties ................................. 18
1.5.1 Minimal State ....................................... 18
1.5.2 Lower-Layer-Protocol Neutral ........................ 18
1.5.3 Text-Based .......................................... 20
2 SIP Uniform Resource Locators ....................... 20
3 SIP Message Overview ................................ 24
4 Request ............................................. 26
4.1 Request-Line ........................................ 26
4.2 Methods ............................................. 27
4.2.1 INVITE .............................................. 28
4.2.2 ACK ................................................. 29
4.2.3 OPTIONS ............................................. 29
4.2.4 BYE ................................................. 30
4.2.5 CANCEL .............................................. 30
4.2.6 REGISTER ............................................ 31
4.3 Request-URI ......................................... 34
4.3.1 SIP Version ......................................... 35
4.4 Option Tags ......................................... 35
4.4.1 Registering New Option Tags with IANA ............... 35
5 Response ............................................ 36
5.1 Status-Line ......................................... 36
5.1.1 Status Codes and Reason Phrases ..................... 37
6 Header Field Definitions ............................ 39
6.1 General Header Fields ............................... 41
6.2 Entity Header Fields ................................ 42
6.3 Request Header Fields ............................... 43
6.4 Response Header Fields .............................. 43
6.5 End-to-end and Hop-by-hop Headers ................... 43
6.6 Header Field Format ................................. 43
6.7 Accept .............................................. 44
6.8 Accept-Encoding ..................................... 44
6.9 Accept-Language ..................................... 45
6.10 Allow ............................................... 45
6.11 Authorization ....................................... 45
6.12 Call-ID ............................................. 46
6.13 Contact ............................................. 47
6.14 Content-Encoding .................................... 50
6.15 Content-Length ...................................... 51
6.16 Content-Type ........................................ 51
6.17 CSeq ................................................ 52
6.18 Date ................................................ 53
6.19 Encryption .......................................... 54
6.20 Expires ............................................. 55
6.21 From ................................................ 56
6.22 Hide ................................................ 57
6.23 Max-Forwards ........................................ 59
6.24 Organization ........................................ 59
6.25 Priority ............................................ 60
6.26 Proxy-Authenticate .................................. 60
6.27 Proxy-Authorization ................................. 61
6.28 Proxy-Require ....................................... 61
6.29 Record-Route ........................................ 62
6.30 Require ............................................. 63
6.31 Response-Key ........................................ 63
6.32 Retry-After ......................................... 64
6.33 Route ............................................... 65
6.34 Server .............................................. 65
6.35 Subject ............................................. 65
6.36 Timestamp ........................................... 66
6.37 To .................................................. 66
6.38 Unsupported ......................................... 68
6.39 User-Agent .......................................... 68
6.40 Via ................................................. 68
6.40.1 Requests ............................................ 68
6.40.2 Receiver-tagged Via Header Fields ................... 69
6.40.3 Responses ........................................... 70
6.40.4 User Agent and Redirect Servers ..................... 70
6.40.5 Syntax .............................................. 71
6.41 Warning ............................................. 72
6.42 WWW-Authenticate .................................... 74
7 Status Code Definitions ............................. 75
7.1 Informational 1xx ................................... 75
7.1.1 100 Trying .......................................... 75
7.1.2 180 Ringing ......................................... 75
7.1.3 181 Call Is Being Forwarded ......................... 75
7.1.4 182 Queued .......................................... 76
7.2 Successful 2xx ...................................... 76
7.2.1 200 OK .............................................. 76
7.3 Redirection 3xx ..................................... 76
7.3.1 300 Multiple Choices ................................ 77
7.3.2 301 Moved Permanently ............................... 77
7.3.3 302 Moved Temporarily ............................... 77
7.3.4 305 Use Proxy ....................................... 77
7.3.5 380 Alternative Service ............................. 78
7.4 Request Failure 4xx ................................. 78
7.4.1 400 Bad Request ..................................... 78
7.4.2 401 Unauthorized .................................... 78
7.4.3 402 Payment Required ................................ 78
7.4.4 403 Forbidden ....................................... 78
7.4.5 404 Not Found ....................................... 78
7.4.6 405 Method Not Allowed .............................. 78
7.4.7 406 Not Acceptable .................................. 79
7.4.8 407 Proxy Authentication Required ................... 79
7.4.9 408 Request Timeout ................................. 79
7.4.10 409 Conflict ........................................ 79
7.4.11 410 Gone ............................................ 79
7.4.12 411 Length Required ................................. 79
7.4.13 413 Request Entity Too Large ........................ 80
7.4.14 414 Request-URI Too Long ............................ 80
7.4.15 415 Unsupported Media Type .......................... 80
7.4.16 420 Bad Extension ................................... 80
7.4.17 480 Temporarily Unavailable ......................... 80
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 81
7.4.19 482 Loop Detected ................................... 81
7.4.20 483 Too Many Hops ................................... 81
7.4.21 484 Address Incomplete .............................. 81
7.4.22 485 Ambiguous ....................................... 81
7.4.23 486 Busy Here ....................................... 82
7.5 Server Failure 5xx .................................. 82
7.5.1 500 Server Internal Error ........................... 82
7.5.2 501 Not Implemented ................................. 82
7.5.3 502 Bad Gateway ..................................... 82
7.5.4 503 Service Unavailable ............................. 83
7.5.5 504 Gateway Time-out ................................ 83
7.5.6 505 Version Not Supported ........................... 83
7.6 Global Failures 6xx ................................. 83
7.6.1 600 Busy Everywhere ................................. 83
7.6.2 603 Decline ......................................... 84
7.6.3 604 Does Not Exist Anywhere ......................... 84
7.6.4 606 Not Acceptable .................................. 84
8 SIP Message Body .................................... 84
8.1 Body Inclusion ...................................... 84
8.2 Message Body Type ................................... 85
8.3 Message Body Length ................................. 85
9 Compact Form ........................................ 85
10 Behavior of SIP Clients and Servers ................. 86
10.1 General Remarks ..................................... 86
10.1.1 Requests ............................................ 86
10.1.2 Responses ........................................... 87
10.2 Source Addresses, Destination Addresses and
Connections ......................................... 88
10.2.1 Unicast UDP ......................................... 88
10.2.2 Multicast UDP ....................................... 88
10.3 TCP ................................................. 89
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
Requests ............................................ 90
10.4.1 UDP ................................................. 90
10.4.2 TCP ................................................. 91
10.5 Reliability for INVITE Requests ..................... 91
10.5.1 UDP ................................................. 92
10.5.2 TCP ................................................. 95
10.6 Reliability for ACK Requests ........................ 95
10.7 ICMP Handling ....................................... 95
11 Behavior of SIP User Agents ......................... 95
11.1 Caller Issues Initial INVITE Request ................ 96
11.2 Callee Issues Response .............................. 96
11.3 Caller Receives Response to Initial Request ......... 96
11.4 Caller or Callee Generate Subsequent Requests ....... 97
11.5 Receiving Subsequent Requests ....................... 97
12 Behavior of SIP Proxy and Redirect Servers .......... 97
12.1 Redirect Server ..................................... 97
12.2 User Agent Server ................................... 98
12.3 Proxy Server ........................................ 98
12.3.1 Proxying Requests ................................... 98
12.3.2 Proxying Responses .................................. 99
12.3.3 Stateless Proxy: Proxying Responses ................. 99
12.3.4 Stateful Proxy: Receiving Requests .................. 99
12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
12.3.6 Stateful Proxy: Receiving Responses ................. 100
12.3.7 Stateless, Non-Forking Proxy ........................ 100
12.4 Forking Proxy ....................................... 100
13 Security Considerations ............................. 104
13.1 Confidentiality and Privacy: Encryption ............. 104
13.1.1 End-to-End Encryption ............................... 104
13.1.2 Privacy of SIP Responses ............................ 107
13.1.3 Encryption by Proxies ............................... 108
13.1.4 Hop-by-Hop Encryption ............................... 108
13.1.5 Via field encryption ................................ 108
13.2 Message Integrity and Access Control:
Authentication ...................................... 109
13.2.1 Trusting responses .................................. 112
13.3 Callee Privacy ...................................... 113
13.4 Known Security Problems ............................. 113
14 SIP Authentication using HTTP Basic and Digest
Schemes ............................................. 113
14.1 Framework ........................................... 113
14.2 Basic Authentication ................................ 114
14.3 Digest Authentication ............................... 114
14.4 Proxy-Authentication ................................ 115
15 SIP Security Using PGP .............................. 115
15.1 PGP Authentication Scheme ........................... 115
15.1.1 The WWW-Authenticate Response Header ................ 116
15.1.2 The Authorization Request Header .................... 117
15.2 PGP Encryption Scheme ............................... 118
15.3 Response-Key Header Field for PGP ................... 119
16 Examples ............................................ 119
16.1 Registration ........................................ 119
16.2 Invitation to a Multicast Conference ................ 121
16.2.1 Request ............................................. 121
16.2.2 Response ............................................ 122
16.3 Two-party Call ...................................... 123
16.4 Terminating a Call .................................. 125
16.5 Forking Proxy ....................................... 126
16.6 Redirects ........................................... 130
16.7 Negotiation ......................................... 131
16.8 OPTIONS Request ..................................... 132
A Minimal Implementation .............................. 134
A.1 Client .............................................. 134
A.2 Server .............................................. 135
A.3 Header Processing ................................... 135
B Usage of the Session Description Protocol (SDP)...... 136
B.1 Configuring Media Streams ........................... 136
B.2 Setting SDP Values for Unicast ...................... 138
B.3 Multicast Operation ................................. 139
B.4 Delayed Media Streams ............................... 139
B.5 Putting Media Streams on Hold ....................... 139
B.6 Subject and SDP "s=" Line ........................... 140
B.7 The SDP "o=" Line ................................... 140
C Summary of Augmented BNF ............................ 141
C.1 Basic Rules ......................................... 143
D Using SRV DNS Records ............................... 146
E IANA Considerations ................................. 148
F Acknowledgments ..................................... 149
G Authors' Addresses .................................. 149
H Bibliography ........................................ 150
I Full Copyright Statement ............................ 153
1 Introduction
1はじめに
The Session Initiation Protocol (SIP) is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. These multimedia sessions include multimedia conferences, distance learning, Internet telephony and similar applications. SIP can invite both persons and "robots", such as a media storage service. SIP can invite parties to both unicast and multicast sessions; the initiator does not necessarily have to be a member of the session to which it is inviting. Media and participants can be added to an existing session.
セッション開始プロトコル（SIP）は、確立、変更、およびマルチメディアセッションまたはコールを終了することができるアプリケーション層制御プロトコルです。これらのマルチメディアセッションは、マルチメディア会議、遠隔教育、インターネット電話と同様のアプリケーションが含まれます。 SIPは、メディアストレージサービスとして、人と「ロボット」の両方を招待することができます。 SIPはユニキャストとマルチキャストセッションの両方の当事者を招待することができます。イニシエータは、必ずしもそれが招待されているセッションのメンバーである必要はありません。メディアと参加者が既存のセッションに追加することができます。
SIP can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means. Sessions can be advertised using multicast protocols such as SAP, electronic mail, news groups, web pages or directories (LDAP), among others.
SIPは、セッションを開始だけでなく、他の手段によって広告と確立されたセッションにメンバーを招待するために使用することができます。セッションは、とりわけ、こうしたSAP、電子メール、ニュースグループ、ウェブページやディレクトリ（LDAP）などのマルチキャストプロトコルを使用して宣伝することができます。
SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility. In the parlance of telecommunications intelligent network services, this is defined as: "Personal mobility is the ability of end users to originate and receive calls and access subscribed telecommunication services on any terminal in any location, and the ability of the network to identify end users as they move. Personal mobility is based on the use of a unique personal identity (i.e., personal number)." [1]. Personal mobility complements terminal mobility, i.e., the ability to maintain communications when moving a single end system from one subnet to another.
SIPは、透過的にISDNおよびインテリジェントネットワーク電話加入者サービスの実装を可能にし、名前のマッピングとリダイレクトサービスをサポートしています。これらの施設はまた、パーソナルモビリティを有効にします。電気通信インテリジェントネットワークサービスの用語では、これは次のように定義されます「パーソナルモビリティは、通話を発信し、受信するエンドユーザーの能力であるとアクセスは任意の場所に任意の端末に通信サービスを加入、およびネットワークの能力は、エンドユーザーを識別するために、彼らは移動する。パーソナルモビリティは、固有の個人識別情報（すなわち、個人番号）の使用に基づいています。」 [1]。パーソナルモビリティは、端末移動性を補完する、すなわち、別の1つのサブネットからシングルエンドシステムを移動する際の通信を維持する能力。
SIP supports five facets of establishing and terminating multimedia communications:
SIPは、マルチメディア通信を確立し、終了の5面をサポートしています。
User location: determination of the end system to be used for communication;
ユーザ位置：通信に使用するエンドシステムの決意。
User capabilities: determination of the media and media parameters to be used;
ユーザ機能：メディアとメディアパラメータの決意を使用します。
User availability: determination of the willingness of the called party to engage in communications;
ユーザーの可用性：通信に従事する着信側の意欲を決意。
Call setup: "ringing", establishment of call parameters at both called and calling party;
コールセットアップ：「リンギング」、両方と呼ばれ、発信者のコール・パラメータの確立。
Call handling: including transfer and termination of calls.
コールハンドリング：通話の転送と終了を含みます。
SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully-meshed interconnection instead of multicast. Internet telephony gateways that connect Public Switched Telephone Network (PSTN) parties can also use SIP to set up calls between them.
SIPはまた、マルチポイント制御ユニット（MCU）またはフルメッシュ配線の代わりにマルチキャストを使用してマルチパーティ呼を開始することができます。公衆交換電話網（PSTN）、当事者を接続するインターネットテレフォニーゲートウェイはまた、それらの間のコールを設定するためにSIPを使用することができます。
SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as RSVP (RFC 2205 [2]) for reserving network resources, the real-time transport protocol (RTP) (RFC 1889 [3]) for transporting real-time data and providing QOS feedback, the real-time streaming protocol (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media, the session announcement protocol (SAP) [5] for advertising multimedia sessions via multicast and the session description protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions. However, the functionality and operation of SIP does not depend on any of these protocols.
SIPは、（RFC 2205 [2]）、リアルタイムトランスポートプロトコル（RTP）を輸送するための（RFC 1889 [3]）、ネットワークリソースを予約するために、現在、RSVPなどのプロトコルを組み込んだ総合的なIETFマルチメディアデータおよび制御アーキテクチャの一部として設計されていますリアルタイムデータと提供QOSフィードバック、リアルタイムストリーミングプロトコル（RTSP）（RFC 2326 [4]）、ストリーミングメディアの配信を制御するために、セッションアナウンスメントプロトコル（SAP）[5]広告マルチメディアセッションのためのマルチキャスト及びビアマルチメディアセッションを記述するセッション記述プロトコル（SDP）（RFC 2327 [6]）。しかし、SIPの機能および操作は、これらのプロトコルのいずれかに依存しません。
SIP can also be used in conjunction with other call setup and signaling protocols. In that mode, an end system uses SIP exchanges to determine the appropriate end system address and protocol from a given address that is protocol-independent. For example, SIP could be used to determine that the party can be reached via H.323 [7], obtain the H.245 [8] gateway and user address and then use H.225.0 [9] to establish the call.
SIPは、他のコールセットアップおよびシグナリングプロトコルと組み合わせて使用することができます。このモードでは、エンド・システムは、プロトコルに依存しない所定のアドレスから適切なエンド・システムのアドレスおよびプロトコルを決定するために、SIP交換を使用します。例えば、SIPは、当事者が[7]、H.245 [8]ゲートウェイとユーザアドレスを取得H.323を介して到達可能であることを決定するために使用し[9]の呼を確立するためにH.225.0を使用することができます。
In another example, SIP might be used to determine that the callee is reachable via the PSTN and indicate the phone number to be called, possibly suggesting an Internet-to-PSTN gateway to be used.
別の例では、SIPは、呼び出し先がPSTNを介して到達可能であり、おそらく使用するインターネットへのPSTNゲートウェイを示唆し、呼び出される電話番号を示すことを決定するために使用されるかもしれません。
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols. SIP does not allocate multicast addresses.
SIPは、フロアコントロールや投票などの会議制御サービスを提供していないとの会議を管理する方法を規定していませんが、SIPは、会議制御プロトコルを導入するために使用することができます。 SIPは、マルチキャストアドレスを割り当てません。
SIP can invite users to sessions with and without resource reservation. SIP does not reserve resources, but can convey to the invited system the information necessary to do this.
SIPは、リソース予約とないセッションにユーザーを招待することができます。 SIPは、リソースを予約しませんが、招待システムにこれを行うために必要な情報を伝えることができます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [10] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119 [10]に記載のコンプライアントSIP実装の要求レベルを示すものとして解釈されるべきです。
This specification uses a number of terms to refer to the roles played by participants in SIP communications. The definitions of client, server and proxy are similar to those used by the Hypertext Transport Protocol (HTTP) (RFC 2068 [11]). The terms and generic syntax of URI and URL are defined in RFC 2396 [12]. The following terms have special significance for SIP.
この仕様は、SIP通信の参加者によって果たされる役割を参照するために多くの用語を使用します。クライアント、サーバ及びプロキシの定義は、ハイパーテキスト転送プロトコル（HTTP）で使用されるものと同様である（RFC 2068 [11]）。 URIとURLの用語や一般的な構文は、RFC 2396 [12]で定義されています。次の用語は、SIPのために特別な意味を持っています。
Call: A call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call-id (Section 6.12). Thus, if a user is, for example, invited to the same multicast session by several people, each of these invitations will be a unique call. A point-to-point Internet telephony conversation maps into a single SIP call. In a multiparty conference unit (MCU) based call-in conference, each participant uses a separate call to invite himself to the MCU.
コール：コールは、共通のソースに招待会議のすべての参加者で構成されています。 SIPコールは、グローバルに一意の呼ID（セクション6.12）によって識別されます。したがって、ユーザーは、例えば、いくつかの人々によって同じマルチキャストセッションに招待されている場合、これらの招待状のそれぞれは、固有の呼び出しになります。ポイント・ツー・ポイント・インターネット電話の会話は、単一のSIPコールにマッピングされます。ベースのマルチパーティ会議ユニット（MCU）にコール会議、各参加者はMCUに自分自身を招待するために別のコールを使用します。
Call leg: A call leg is identified by the combination of Call-ID, To and From.
コールレグ：コールレッグをして、より、コール-IDの組み合わせによって識別されます。
Client: An application program that sends SIP requests. Clients may or may not interact directly with a human user. User agents and proxies contain clients (and servers).
クライアント：SIPリクエストを送信するアプリケーションプログラム。クライアントは、あるいは人間のユーザと直接対話しない場合があります。ユーザエージェントとプロキシは、クライアント（およびサーバ）が含まれています。
Conference: A multimedia session (see below), identified by a common session description. A conference can have zero or more members and includes the cases of a multicast conference, a full-mesh conference and a two-party "telephone call", as well as combinations of these. Any number of calls can be used to create a conference.
会議：マルチメディアセッション（下記参照）、一般的なセッション記述によって同定しました。会議は、ゼロ以上のメンバーを持っていると、マルチキャスト会議、フルメッシュ会議と二大政党「電話」の例、ならびにこれらの組合せを含むことができます。呼び出しの任意の数の会議を作成するために使用することができます。
Downstream: Requests sent in the direction from the caller to the callee (i.e., 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の応答が最終的なものです。
Initiator, calling party, caller: The party initiating a conference invitation. Note that the calling party does not have to be the same as the one creating the conference.
イニシエータ、発信者、呼び出し元：会議の招待状を開始するパーティー。発呼者が会議を作成するものと同じである必要はないことに注意してください。
Invitation: A request sent to a user (or service) requesting participation in a session. A successful SIP invitation consists of two transactions: an INVITE request followed by an ACK request.
招待：セッションへの参加を要求するユーザ（またはサービス）に送信された要求。 ACK要求に続くINVITE要求：成功したSIP招待は、二つのトランザクションから構成されています。
Invitee, invited user, called party, callee: The person or service that the calling party is trying to invite to a conference.
招待、招待されたユーザーと呼ばれるパーティー、呼び出し先：発呼者が会議に招待しようとしている人またはサービス。
Isomorphic request or response: Two requests or responses are defined to be isomorphic for the purposes of this document if they have the same values for the Call-ID, To, From and CSeq header fields. In addition, isomorphic requests have to have the same Request-URI.
同形の要求や応答は：2つの要求または応答が、彼らはとCSeqヘッダーフィールドから、には、Call-IDと同じ値を持っている場合は、この文書の目的のために同型になるように定義されています。また、同型の要求は、同じ要求URIを持っている必要があります。
Location server: See location service.
ロケーションサーバ：ロケーションサービスを参照してください。
Location service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). Location services are offered by location servers. Location servers MAY be co-located with a SIP server, but the manner in which a SIP server requests location services is beyond the scope of this document.
ロケーションサービス：ロケーションサービスは、被呼者の可能な位置（単数または複数）についての情報を得るために、SIPリダイレクトまたはプロキシサーバによって使用されます。位置情報サービスは、ロケーションサーバによって提供されています。ロケーションサーバは、SIPサーバとの共配置することができるが、SIPサーバは、ロケーションサービスを要求する方法は、このドキュメントの範囲を超えています。
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.
並列検索は：並列検索では、プロキシは、着信要求を受信することが可能とユーザの場所にいくつかのリクエストを発行します。むしろ一つのリクエストを発行し、その後、順次検索のように次のリクエストを発行する前に、最終的な応答を待っているよりも、以前の要求の結果を待たずに並列検索要求を発行。
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 program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it.
プロキシ、プロキシサーバ：他のクライアントに代わってリクエストを作成する目的のために、サーバーとクライアントの両方として動作する仲介プログラム。リクエストは、内部または他のサーバーに、おそらく翻訳後、それらを渡すことによってサービスされています。プロキシは、必要であれば、それを転送する前に、要求メッセージを書き換え、解釈、および。
Redirect server: A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server , it does not initiate its own SIP request. Unlike a user agent server , it does not accept calls.
サーバーのリダイレクト：リダイレクトサーバは、SIP要求を受け付け、ゼロ以上の新しいアドレスにアドレスをマッピングし、クライアントにこれらのアドレスを返すサーバです。プロキシサーバーとは異なり、それは自身のSIP要求を開始しません。ユーザエージェントサーバとは異なり、それは呼び出しを受け付けません。
Registrar: A registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and MAY offer location services.
レジストラ：レジストラがREGISTER要求を受け入れるサーバーです。レジストラは、通常のプロキシと同じ場所に配置またはサーバーにリダイレクトされ、ロケーションサービスを提供することがあります。
Ringback: Ringback is the signaling tone produced by the calling client's application indicating that a called party is being alerted (ringing).
リングバック：リングバックと呼ばれるパーティが（リンギング）を警告されていることを示す呼び出して、クライアントのアプリケーションによって生成さシグナリングトーンです。
Server: A server is an application program that accepts requests in order to service requests and sends back responses to those requests. Servers are either proxy, redirect or user agent servers or registrars.
サーバー：サーバーは、サービス要求するために、要求を受け入れ、これらの要求に対する応答を返信するアプリケーションプログラムです。サーバーは、リダイレクトやユーザエージェントサーバやレジストラのいずれかのプロキシです。
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 [6]) (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 user name , session id , network type , address type and address elements in the origin field.
セッション：SDP仕様からは：「マルチメディアセッションは、マルチメディア送信者と受信者と受信者に送信者から流れるデータストリームのセットであるマルチメディア会議は、マルチメディアセッションの一例です。」。 （RFC 2327 [6]）（SDPについて定義した通りセッションは、1つ以上のRTPセッションを含むことができる。）で定義されるように、被呼者が同じセッションに、異なる呼び出しによって、複数回招待することができます。 SDPが使用される場合、セッションは原点フィールドにユーザ名、セッションID、ネットワークタイプ、アドレスタイプおよびアドレスの要素の連結によって定義されます。
(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 sent from the server to the client. A transaction is identified by the CSeq sequence number (Section 6.17) within a single call leg. The ACK request has the same CSeq number as the corresponding INVITE request, but comprises a transaction of its own.
（SIP）トランザクション：SIPトランザクションは、クライアントとサーバとの間で発生し、サーバーからクライアントに送信され、最終的な（非1XX）応答までクライアントからサーバに送信された最初の要求からすべてのメッセージを含みます。トランザクションは、単一のコールレッグ内のCSeqシーケンス番号（セクション6.17）によって識別されます。 ACK要求は、INVITE要求を、対応する同様のCSeq番号を有するが、それ自身のトランザクションを含みます。
Upstream: Responses sent in the direction from the user agent server to the user agent client.
上流：ユーザー・エージェント・クライアントにユーザエージェントサーバからの方向に送られた応答。
URL-encoded: A character string encoded according to RFC 1738, Section 2.2 [13].
URLエンコード：RFC 1738に従ってエンコードされた文字列、セクション2.2 [13]。
User agent client (UAC), calling user agent: A user agent client is a client application that initiates the SIP request.
ユーザエージェントクライアント（UAC）、ユーザーエージェントを呼び出す：ユーザー・エージェント・クライアントは、SIPリクエストを開始するクライアントアプリケーションです。
User agent server (UAS), called user agent: A user agent server is a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects or redirects the request.
ユーザエージェントと呼ばれるユーザエージェントサーバ（UAS）：ユーザエージェントサーバは、SIP要求を受信し、それがユーザーに代わって応答を返しているコンタクトユーザサーバアプリケーションです。応答は要求を拒否またはリダイレクトし、受け入れます。
User agent (UA): An application which contains both a user agent client and user agent server.
ユーザーエージェント（UA）：ユーザー・エージェント・クライアントとユーザエージェントサーバの両方を含むアプリケーション。
An application program MAY be capable of acting both as a client and a server. For example, a typical multimedia conference control application would act as a user agent client to initiate calls or to invite others to conferences and as a user agent server to accept invitations. The properties of the different SIP server types are summarized in Table 1.
アプリケーションプログラムは、クライアントとサーバーの両方として作用することが可能であってもよいです。例えば、典型的なマルチメディア会議制御アプリケーションは、コールを開始したり、会議にとの招待を受け入れるために、ユーザエージェントサーバとして他のユーザーを招待するためにユーザエージェントクライアントとして動作します。異なるSIPサーバの種類の特性を表1にまとめます。
property redirect proxy user agent registrar
server server server
__________________________________________________________________
also acts as a SIP client no yes no no
returns 1xx status yes yes yes yes
returns 2xx status no yes yes yes
returns 3xx status yes yes yes yes
returns 4xx status yes yes yes yes
returns 5xx status yes yes yes yes
returns 6xx status no yes yes yes
inserts Via header no yes no no
accepts ACK yes yes yes no
Table 1: Properties of the different SIP server types
表1：別のSIPサーバタイプのプロパティ
This section explains the basic protocol functionality and operation. Callers and callees are identified by SIP addresses, described in Section 1.4.1. When making a SIP call, a caller first locates the appropriate server (Section 1.4.2) and then sends a SIP request (Section 1.4.3). The most common SIP operation is the invitation (Section 1.4.4). Instead of directly reaching the intended callee, a SIP request may be redirected or may trigger a chain of new SIP requests by proxies (Section 1.4.5). Users can register their location(s) with SIP servers (Section 4.2.6).
このセクションでは、基本的なプロトコル機能と操作方法について説明します。発信者や呼び出し先は、1.4.1項で説明したSIPアドレスによって識別されます。 SIPコールを行うとき、呼び出し側は、最初に適切なサーバ（項1.4.2）を見つけ、次にSIP要求（項1.4.3）を送信します。最も一般的なSIP操作が招待（1.4.4項）です。代わりに直接意図呼び出し先に到達する、SIP要求がリダイレクトされ得るか、またはプロキシ（セクション1.4.5）によって新しいSIPリクエストのチェーンをトリガすることができます。ユーザーは、SIPサーバ（4.2.6）で自分の場所（複数可）を登録することができます。
The "objects" addressed by SIP are users at hosts, identified by a SIP URL. The SIP URL takes a form similar to a mailto or telnet URL, i.e., user@host. The user part is a user name or a telephone number. The host part is either a domain name or a numeric network address. See section 2 for a detailed discussion of SIP URL's.
SIPによって対処「オブジェクトは、」SIPのURLによって識別されるホストでのユーザー、です。 SIP URLホスト@すなわち、ユーザ、MAILTOまたはtelnet URLと同様の形式をとります。ユーザ部分には、ユーザー名や電話番号です。ホスト部分は、ドメイン名または数値ネットワークアドレスのどちらかです。 SIP URLのの詳細な議論のためのセクション2を参照してください。
A user's SIP address can be obtained out-of-band, can be learned via existing media agents, can be included in some mailers' message headers, or can be recorded during previous invitation interactions. In many cases, a user's SIP URL can be guessed from their email address.
ユーザーのSIPアドレスは、帯域外得ることができ、既存のメディア・エージェントを経由して学習することができる、いくつかのメーラーメッセージヘッダに含めることができ、又は以前招待相互作用の中に記録することができます。多くの場合、ユーザーのSIP URLは、自分のメールアドレスから推測することができます。
A SIP URL address can designate an individual (possibly located at one of several end systems), the first available person from a group of individuals or a whole group. The form of the address, for example, sip:sales@example.com , is not sufficient, in general, to determine the intent of the caller.
SIP URLアドレスは、（おそらく、いくつかのエンドシステムのいずれかに位置する）個人、個人のグループ又はグループ全体から最初に使用可能な人を指定することができます。アドレスの形式は、例えば、SIP：sales@example.com、発信者の意図を決定するために、一般的には、十分ではありません。
If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation, the traditional method of ensuring privacy by having an unlisted "phone" number is compromised. However, unlike traditional telephony, SIP offers authentication and access control mechanisms and can avail itself of lower-layer security mechanisms, so that client software can reject unauthorized or undesired call attempts.
ユーザやサービスが、人の名前や所属組織から推測可能であるアドレスに到達可能であることを選択した場合、非上場の「電話」番号を持つことで、プライバシーを確保する伝統的な方法が危険にさらされています。しかし、従来の電話とは異なり、SIPは、認証とアクセス制御メカニズムを提供し、クライアントソフトウェアが不正または望ましくないコールの試行を拒否することができるように、下位層のセキュリティメカニズムの自分自身を役に立つことができます。
When a client wishes to send a request, the client either sends it to a locally configured SIP proxy server (as in HTTP), independent of the Request-URI, or sends it to the IP address and port corresponding to the Request-URI.
クライアントが要求を送信したい場合、クライアントは、Request-URIから独立し、（HTTPのように）ローカルに設定されたSIPプロキシサーバに送信し、またはリクエストURIに対応するIPアドレスとポートに送信いずれか。
For the latter case, the client must determine the protocol, port and IP address of a server to which to send the request. A client SHOULD follow the steps below to obtain this information, but MAY follow the alternative, optional procedure defined in Appendix D. At each step, unless stated otherwise, the client SHOULD try to contact a server at the port number listed in the Request-URI. If no port number is present in the Request-URI, the client uses port 5060. If the Request-URI specifies a protocol (TCP or UDP), the client contacts the server using that protocol. If no protocol is specified, the client tries UDP (if UDP is supported). If the attempt fails, or if the client doesn't support UDP but supports TCP, it then tries TCP.
後者の場合、クライアントはリクエストの送信先となるサーバのプロトコル、ポートおよびIPアドレスを決定する必要があります。クライアントがこの情報を入手するには、以下の手順に従ってくださいが、代替に従うことができる、特に断りのない限り、各ステップでは、付録Dで定義されたオプションの手順は、クライアントが要求 - に記載されているポート番号でサーバに接続しようとする必要がありますURI。ポート番号が要求URIに存在しない場合のRequest-URIはプロトコル（TCPまたはUDP）、クライアントはそのプロトコルを使用してサーバーを指定する場合、クライアントは、ポート5060を使用しています。プロトコルが指定されていない場合は（UDPがサポートされている場合）、クライアントはUDPをしようとします。試みが失敗した場合、クライアントはUDPをサポートしますが、TCPをサポートしていない場合、または、それは、TCPをしようとします。
A client SHOULD be able to interpret explicit network notifications (such as ICMP messages) which indicate that a server is not reachable, rather than relying solely on timeouts. (For socket-based programs: For TCP, connect() returns ECONNREFUSED if the client could not connect to a server at that address. For UDP, the socket needs to be bound to the destination address using connect() rather than sendto() or similar so that a second write() fails with ECONNREFUSED if there is no server listening) If the client finds the server is not reachable at a particular address, it SHOULD behave as if it had received a 400-class error response to that request.
クライアントは、サーバーではなくタイムアウトのみに頼るよりも、到達できないことを示している（例えばICMPメッセージなど）の明示的なネットワークの通知を解釈することができるべきです。 （ソケットベースのプログラムの場合：TCPの場合は、クライアントがそのアドレスでサーバーに接続できませんでした場合はECONNREFUSEDを返す）（接続UDPの場合は、ソケットはむしろのsendto以外）（接続使用して宛先アドレスにバインドする必要があります（）。または類似まったくサーバーのリスニングが存在しない場合は、2番目の書き込みは（）ECONNREFUSEDで失敗するように）クライアントは、サーバが特定のアドレスでは到達できない見つけた場合、それはその要求に400クラスのエラー応答を受信したかのように、それが振る舞うべき。
The client tries to find one or more addresses for the SIP server by querying DNS. The procedure is as follows:
クライアントは、DNSを照会することにより、SIPサーバのための1つ以上のアドレスを見つけようとします。手順は以下の通りです。
1. If the host portion of the Request-URI is an IP address,
the client contacts the server at the given address.
Otherwise, the client proceeds to the next step.
2. The client queries the DNS server for address records for the host portion of the Request-URI. If the DNS server returns no address records, the client stops, as it has been unable to locate a server. By address record, we mean A RR's, AAAA RR's, or other similar address records, chosen according to the client's network protocol capabilities.
2.クライアントは、Request-URIのホスト部分のためのアドレスレコードのDNSサーバーを照会します。 DNSサーバーは何のアドレスレコードを返さない場合は、サーバーを見つけることができなかったとして、クライアントは、停止します。アドレスレコードによって、我々はRRの、AAAA RRの、または他の同様のアドレスレコード、クライアントのネットワークプロトコル能力に応じて選択を意味します。
There are no mandatory rules on how to select a host name for a SIP server. Users are encouraged to name their SIP servers using the sip.domainname (i.e., sip.example.com) convention, as specified in RFC 2219 [16]. Users may only know an email address instead of a full SIP URL for a callee, however. In that case, implementations may be able to increase the likelihood of reaching a SIP server for that domain by constructing a SIP URL from that email address by prefixing the host name with "sip.". In the future, this mechanism is likely to become unnecessary as better DNS techniques, such as the one in Appendix D, become widely available.
SIPサーバのホスト名を選択する方法には必須のルールはありません。 RFC 2219で指定されるようにユーザーが[16]、sip.domainname（すなわち、sip.example.com）規則を使用してSIPサーバに名前を付けることが推奨されます。ユーザーは、しかし、代わりに呼び出し先の完全なSIPのURLのメールアドレスを知っているかもしれません。その場合、実装はしてホスト名を付けることによって、そのメールアドレスからのSIP URLを構築することにより、そのドメインのSIPサーバに到達する可能性を高めることができるかもしれ「一口。」。将来的には、このメカニズムは、そのような広く利用可能になっ付録D内の1つの、より良いようにDNS技術、などが不要となる可能性があります。
A client MAY cache a successful DNS query result. A successful query is one which contained records in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes to send a request to the same host, it MUST start the search as if it had just received this answer from the name server. The client MUST follow the procedures in RFC1035 [15] regarding DNS cache invalidation when the DNS time-to-live expires.
クライアントは、成功したDNSクエリの結果をキャッシュすることができます。成功したクエリが答えでレコードを含まれる1つであり、サーバは答えからのアドレスのいずれかで接触させました。クライアントが同じホストに要求を送信したい場合には、それだけでネームサーバからこの回答を受けたかのように、それは、検索を開始しなければなりません。 DNSの生存時間の期限が切れたとき、クライアントは、DNSキャッシュの無効化についてはRFC1035 [15]の手順に従わなければなりません。
Once the host part has been resolved to a SIP server, the client sends one or more SIP requests to that server and receives one or more responses from the server. A request (and its retransmissions) together with the responses triggered by that request make up a SIP transaction. All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. The ACK request following an INVITE is not part of the transaction since it may traverse a different set of hosts.
ホスト部分は、SIPサーバに解決された後、クライアントはそのサーバーへの1つ以上のSIPリクエストを送信し、サーバから1つの以上の応答を受け取ります。一緒にその要求によってトリガ応答と要求（とその再送信）はSIPトランザクションを構成しています。要求への応答はすべてのCall-IDには、のCSeq、同じ値が含まれていると、Fromフィールド（タグの可能性に加えて（To]フィールドにセクション6.37））。これは、応答が要求と一致することができます。 INVITE次のACK要求は、ホストの異なるセットを横断することができるので、トランザクションの一部ではありません。
If TCP is used, request and responses within a single SIP transaction are carried over the same TCP connection (see Section 10). Several SIP requests from the same client to the same server MAY use the same TCP connection or MAY use a new connection for each request.
TCPが使用されている場合は、1つのSIPトランザクション内の要求と応答が同じTCP接続を介して運ばれる（セクション10を参照）。同じサーバに同じクライアントから複数のSIP要求が同じTCP接続を使用したり、要求ごとに新しい接続を使用するかもしれません。
If the client sent the request via unicast UDP, the response is sent to the address contained in the next Via header field (Section 6.40) of the response. If the request is sent via multicast UDP, the response is directed to the same multicast address and destination port. For UDP, reliability is achieved using retransmission (Section 10).
クライアントは、ユニキャストUDPを介して要求を送信した場合、応答は、応答の次のViaヘッダフィールド（セクション6.40）に含まれるアドレスに送信されます。要求はマルチキャストUDPを介して送信された場合、応答は同じマルチキャストアドレスおよび宛先ポートに向けられています。 UDPは、信頼性が再送信（セクション10）を使用して達成されます。
The SIP message format and operation is independent of the transport protocol.
SIPメッセージフォーマット及び操作は、トランスポートプロトコルとは無関係です。
A successful SIP invitation consists of two requests, INVITE followed by ACK. The INVITE (Section 4.2.1) request asks the callee to join a particular conference or establish a two-party conversation. After the callee has agreed to participate in the call, the caller confirms that it has received that response by sending an ACK (Section 4.2.2) request. If the caller no longer wants to participate in the call, it sends a BYE request instead of an ACK.
成功したSIP招待は、2つの要求、INVITE ACKが続くから構成されています。 （4.2.1）をINVITE要求は、特定の会議に参加するか、二者通話を確立するために、呼び出し先を要求します。呼び出し先が通話に参加することに合意した後、呼び出し側は、それがACK（4.2.2）要求を送信することによって、その応答を受信したことを確認します。呼び出し側は、もはや通話に参加を希望する場合は、代わりにACKのBYE要求を送信しません。
The INVITE request typically contains a session description, for example written in SDP (RFC 2327 [6]) format, that provides the called party with enough information to join the session. For multicast sessions, the session description enumerates the media types and formats that are allowed to be distributed to that session. For a unicast session, the session description enumerates the media types and formats that the caller is willing to use and where it wishes the media data to be sent. In either case, if the callee wishes to accept the call, it responds to the invitation by returning a similar description listing the media it wishes to use. For a multicast session, the callee SHOULD only return a session description if it is unable to receive the media indicated in the caller's description or wants to receive data via unicast.
INVITE要求は、典型的には、セッションに参加するのに十分な情報を被呼者に提供するSDP（RFC 2327 [6]）形式で記述された、例えば、セッション記述を含んでいます。マルチキャストセッションの場合、セッション記述は、セッションに配信することが許可されているメディアタイプとフォーマットを列挙する。ユニキャストセッションのために、セッション記述は、発信者が使用する意思があると、それはメディアデータを望む場合に送信されるメディアタイプとフォーマットを列挙する。呼び出し先が呼び出しを受け入れることを希望する場合はいずれの場合も、それが使用したいメディアをリスト同様の記述を返すことによって、招待に応答します。呼び出し側の説明に示されたメディアを受信することができないか、ユニキャストを介してデータを受信したい場合、マルチキャストセッションの場合、呼び出し先が唯一のセッション記述を返すべきです。
The protocol exchanges for the INVITE method are shown in Fig. 1 for a proxy server and in Fig. 2 for a redirect server. (Note that the messages shown in the figures have been abbreviated slightly.) In Fig. 1, the proxy server accepts the INVITE request (step 1), contacts the location service with all or parts of the address (step 2) and obtains a more precise location (step 3). The proxy server then issues a SIP INVITE request to the address(es) returned by the location service (step 4). The user agent server alerts the user (step 5) and returns a success indication to the proxy server (step
INVITEメソッドのためのプロトコル交換は、図1に示されているプロキシサーバおよび図2リダイレクトサーバ用。 （図に示すメッセージがわずかに略記されていることに注意してください。）図1において、プロキシサーバは、要求（ステップ1）、コンタクトアドレスの全部または一部とロケーションサービスをINVITE（ステップ2）を受け入れ、取得より正確な位置（ステップ3）。プロキシサーバは、SIPは、ロケーションサービス（ステップ4）によって返されたアドレス（複数可）にINVITE要求を発行します。ユーザエージェントサーバは、ユーザ（ステップ5）を警告し、プロキシサーバー（ステップに成功指示が返さ
6). The proxy server then returns the success result to the original caller (step 7). The receipt of this message is confirmed by the caller using an ACK request, which is forwarded to the callee (steps 8 and 9). Note that an ACK can also be sent directly to the callee, bypassing the proxy. All requests and responses have the same Call-ID.
6）。プロキシサーバは、元の呼び出し元（ステップ7）に成功した結果を返します。このメッセージの受信は、被呼者に転送されるACK要求を用いて発呼者によって確認された（8ステップ、および9）。 ACKはまた、プロキシをバイパスし、被呼者に直接送信することができることに留意されたいです。すべての要求と応答が同じCall-IDを持っています。
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ 4: INVITE 5: ring :
: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................( )<.........( ) :
: : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( work ) ( lab ) :
: : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+
====> SIP request ....> SIP response
====> SIPリクエスト...> SIP応答
^ | non-SIP protocols |
^ |非SIPプロトコル|
Figure 1: Example of SIP proxy server
図1：SIPプロキシサーバの例
The redirect server shown in Fig. 2 accepts the INVITE request (step 1), contacts the location service as before (steps 2 and 3) and, instead of contacting the newly found address itself, returns the address to the caller (step 4), which is then acknowledged via an ACK request (step 5). The caller issues a new request, with the same call-ID but a higher CSeq, to the address returned by the first server (step 6). In the example, the call succeeds (step 7). The caller and callee complete the handshake with an ACK (step 8).
図4に示すリダイレクトサーバ2は、INVITE要求（ステップ1）、前のようにコンタクトロケーションサービスを（2ステップ3）と、代わりに、新たに見つかったアドレス自体を接触させる、呼び出し元にアドレスを返す受け付ける（ステップ4） 、その後ACK要求によって確認応答される（ステップ5）。呼び出し側は、最初のサーバー（ステップ6）によって返されたアドレスに、同じコール-IDが、より高いのCSeqと、新しい要求を発行します。一例では、コールは（ステップ7）が成功しています。呼び出し元と呼び出し先は、ACK（ステップ8）を用いてハンドシェイクを完了する。
The next section discusses what happens if the location service returns more than one possible alternative.
次のセクションでは、ロケーション・サービスは、複数の可能な選択肢を返す場合、何が起こるかを説明します。
A callee may move between a number of different end systems over time. These locations can be dynamically registered with the SIP server (Sections 1.4.7, 4.2.6). A location server MAY also use one or more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC 2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or operating-system dependent mechanisms to actively determine the end system where a user might be reachable. A location server MAY return several locations because the user is logged in at several hosts simultaneously or because the location server has (temporarily) inaccurate information. The SIP server combines the results to yield a list of a zero or more locations.
被呼者は、時間をかけて異なるエンドシステムの数との間で移動することができます。これらの位置は、動的にSIPサーバ（セクション1.4.7、4.2.6）に登録することができます。ロケーションサーバはまた、指（RFC 1288 [17]）、rwhois（RFC 2167 [18]）、LDAP（RFC 1777 [19]）、マルチキャストベースのプロトコル[20]または動作などの1つまたは複数の他のプロトコルを使用してもよいです積極的にユーザが到達可能であるかもしれないエンドシステムを決定するために依存するメカニズムを-system。ユーザが同時に又はロケーションサーバは、（一時的に）不正確な情報を持っているので、複数のホストにログインしているので、ロケーションサーバは、いくつかの場所を返すことができます。 SIPサーバは、ゼロ以上の場所のリストを生成するために結果を結合します。
The action taken on receiving a list of locations varies with the type of SIP server. A SIP redirect server returns the list to the client as Contact headers (Section 6.13). A SIP proxy server can sequentially or in parallel try the addresses until the call is successful (2xx response) or the callee has declined the call (6xx response). With sequential attempts, a proxy server can implement an "anycast" service.
場所のリストを受信すると実行されるアクションは、SIPサーバの種類によって変化します。 SIPリダイレクトサーバは、Contactヘッダ（セクション6.13）としてクライアントにリストを返します。呼び出しが成功した（2XX応答）または被呼者が呼（の6xxレスポンス）を辞退するまでSIPプロキシサーバは、順次または並列にアドレスを試みることができます。シーケンシャルの試みでは、プロキシサーバは、「エニーキャスト」サービスを実装することができます。
If a proxy server forwards a SIP request, it MUST add itself to the beginning of the list of forwarders noted in the Via (Section 6.40) headers. The Via trace ensures that replies can take the same path back, ensuring correct operation through compliant firewalls and avoiding request loops. On the response path, each host MUST remove its Via, so that routing internal information is hidden from the callee and outside networks. A proxy server MUST check that it does not generate a request to a host listed in the Via sent-by, via-received or via-maddr parameters (Section 6.40). (Note: If a host has several names or network addresses, this does not always work. Thus, each host also checks if it is part of the Via list.)
プロキシサーバは、SIP要求を転送した場合、それは経由（セクション6.40）ヘッダに記載フォワーダのリストの先頭に自分自身を追加しなければなりません。経由トレースは、回答に準拠してファイアウォールを介し正しい動作を保証し、リクエストループを避け、バック同じパスを取ることができることを保証します。ルーティング内部情報は、被呼者と外部ネットワークから隠されるように、応答経路上に、各ホストは、そのビアを削除する必要があります。プロキシサーバは、受信を介して、または経由-MADDRパラメータ（項6.40）、それは介して送信されるごとにリストされているホストへの要求が発生しないことをチェックしなければなりません。 （注意：ホストはいくつかの名前またはネットワークアドレスを持っている場合、これは常に動作しません、それは経由リストの一部である場合はこのように、各ホストもチェックします。）
A SIP invitation may traverse more than one SIP proxy server. If one of these "forks" the request, i.e., issues more than one request in response to receiving the invitation request, it is possible that a client is reached, independently, by more than one copy of the invitation request. Each of these copies bears the same Call-ID. The user agent MUST return the same status response returned in the first response. Duplicate requests are not an error.
SIP招待は、複数のSIPプロキシサーバを通過することができます。これらの「フォーク」要求、招待要求を受信することに応答して1つの要求よりも、すなわち、問題のうち1つ以上あれば、クライアントは招待要求の複数のコピーによって、独立して、到達している可能性があります。これらのコピーはそれぞれ、同じCall-IDを負いません。ユーザーエージェントは、最初の応答で返さ同じステータス応答を返さなければなりません。重複したリクエストはエラーではありません。
In some circumstances, it is desirable to change the parameters of an existing session. This is done by re-issuing the INVITE, using the same Call-ID, but a new or different body or header fields to convey the new information. This re INVITE MUST have a higher CSeq than any previous request from the client to the server.
いくつかの状況では、既存のセッションのパラメータを変更することが望ましいです。これは、同じCall-IDを使用して、INVITEを再発行することによって行われますが、新規または異なる身体またはヘッダフィールドは、新たな情報を伝えるために。これは、クライアントからサーバーへの以前の要求よりも高いのCSeqを持たなければならないINVITE再。
For example, two parties may have been conversing and then want to add a third party, switching to multicast for efficiency. One of the participants invites the third party with the new multicast address and simultaneously sends an INVITE to the second party, with the new multicast session description, but with the old call identifier.
たとえば、2つの当事者は会話した後、第三者を追加したい、効率のためにマルチキャストに切り替えられている場合があります。参加者の一人は、新しいマルチキャストアドレスで、第三者を誘うと同時に、新たなマルチキャストセッション記述ではなく、古いコール識別子と、第二のパーティにINVITEを送信します。
The REGISTER request allows a client to let a proxy or redirect server know at which address(es) it can be reached. A client MAY also use it to install call handling features at the server.
REGISTERリクエストは、プロキシを聞かせたり、サーバーをリダイレクトするクライアントは、それが到達できるアドレス（複数可）で知ることができます。また、クライアントは、サーバでのコール処理機能をインストールするためにそれを使用することができます。
A single conference session or call involves one or more SIP request-response transactions. Proxy servers do not have to keep state for a particular call, however, they MAY maintain state for a single SIP transaction, as discussed in Section 12. For efficiency, a server MAY cache the results of location service requests.
1つの会議セッションまたはコールは、一つ以上のSIP要求 - 応答トランザクションを必要とします。プロキシサーバーは、サーバーがロケーションサービス要求の結果をキャッシュするかもしれ、効率化のため、セクション12で説明したようにしかし、彼らは、単一のSIPトランザクションの状態を維持することができる、特定のコールの状態を維持する必要はありません。
SIP makes minimal assumptions about the underlying transport and network-layer protocols. The lower-layer can provide either a packet or a byte stream service, with reliable or unreliable service.
SIPは、基礎となるトランスポートとネットワーク層のプロトコルについての最小限の仮定を行います。下位層は、信頼性や信頼性の低いサービスで、パケットまたはバイトストリームのサービスのいずれかを提供することができます。
In an Internet context, SIP is able to utilize both UDP and TCP as transport protocols, among others. UDP allows the application to more carefully control the timing of messages and their retransmission, to perform parallel searches without requiring TCP connection state for each outstanding request, and to use multicast. Routers can more readily snoop SIP UDP packets. TCP allows easier passage through existing firewalls.
インターネットの文脈では、SIPは、とりわけ、トランスポートプロトコルとしてUDPおよびTCPの両方を利用することができます。 UDPは、アプリケーションがより慎重に各未処理の要求のためのTCP接続状態を必要とすることなく、並列検索を実行するために、メッセージのタイミングおよびそれらの再送を制御することができ、およびマルチキャストを使用します。ルータは、より容易にSIP UDPパケットをスヌープすることができます。 TCPは、既存のファイアウォールを通して簡単に通過することができます。
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request ....> SIP response
====> SIPリクエスト...> SIP応答
^ | non-SIP protocols |
^ |非SIPプロトコル|
Figure 2: Example of SIP redirect server
図2：SIPリダイレクトサーバの例
When TCP is used, SIP can use one or more connections to attempt to contact a user or to modify parameters of an existing conference. Different SIP requests for the same SIP call MAY use different TCP connections or a single persistent connection, as appropriate.
TCPを使用する場合、SIPは、ユーザーに連絡するか、既存の会議のパラメータを変更しようとする1つまたは複数の接続を使用することができます。同じSIPコールのためのさまざまなSIPリクエストは、必要に応じて、異なるTCP接続または単一の持続的接続を使用するかもしれません。
For concreteness, this document will only refer to Internet protocols. However, SIP MAY also be used directly with protocols such as ATM AAL5, IPX, frame relay or X.25. The necessary naming conventions are beyond the scope of this document. User agents SHOULD implement both UDP and TCP transport. Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport.
具体性のために、このドキュメントは、インターネット・プロトコルを参照します。しかしながら、SIPはまた、ATM AAL5、IPX、フレームリレーまたはX.25などのプロトコルを用いてそのまま用いてもよいです。必要な命名規則は、このドキュメントの範囲を超えています。ユーザエージェントは、UDPとTCPトランスポートの両方を実装する必要があります。プロキシ、レジストラ、およびリダイレクトサーバーは、UDPとTCPトランスポートの両方を実装しなければなりません。
SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This allows easy implementation in languages such as Java, Tcl and Perl, allows easy debugging, and most importantly, makes SIP flexible and extensible. As SIP is used for initiating multimedia conferences rather than delivering media data, it is believed that the additional overhead of using a text-based protocol is not significant.
SIPは、全体でUTF-8エンコーディングにISO 10646を使用して、テキストベースです。これは、Javaの、TclとPerlなどの言語で簡単に実装することができます簡単なデバッグを可能にし、最も重要なのは、SIPは、柔軟で拡張可能。 SIPは、マルチメディア会議を開始するのではなく、メディアデータを配信するために使用されるように、テキストベースのプロトコルを使用して、追加のオーバーヘッドが重要でないと考えられています。
2 SIP Uniform Resource Locators
2 SIPユニフォームリソースロケータ
SIP URLs are used within SIP messages to indicate the originator (From), current destination (Request-URI) and final recipient (To) of a SIP request, and to specify redirection addresses (Contact). A SIP URL can also be embedded in web pages or other hyperlinks to indicate that a particular user or service can be called via SIP. When used as a hyperlink, the SIP URL indicates the use of the INVITE method.
SIP URLは、発信者（から）、現在の宛先（要求URI）と、最終的な受信者を示すために、SIPリクエストの（TO）、および（接触）リダイレクトアドレスを指定するSIPメッセージ内で使用されます。 SIP URLは、特定のユーザーまたはサービスがSIP経由で呼び出すことができることを示すために、Webページや他のハイパーリンクに埋め込むことができます。ハイパーリンクとして使用される場合、SIP URLは、INVITEメソッドの使用を示しています。
The SIP URL scheme is defined to allow setting SIP request-header fields and the SIP message-body.
SIP URLスキームは、SIPリクエスト・ヘッダー・フィールドとSIPメッセージボディを設定できるように定義されます。
This corresponds to the use of mailto: URLs. It makes it
possible, for example, to specify the subject, urgency or
media types of calls initiated through a web page or as
part of an email message.
A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax shown in Fig. 3. The syntax is described using Augmented Backus-Naur Form (See Section C). Note that reserved characters have to be escaped and that the "set of characters 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" [12].
SIP URLはRFC 2396 [12]のガイドラインに従い、図1に示した構文を有する。3.構文を増補バッカスナウア記法を用いて説明する（セクションCを参照）。予約文字をエスケープしてする必要があることに注意する「任意のURIコンポーネントは、そのコンポーネントによって定義される範囲内に予約文字のセット。一般的には、文字はURIのセマンティクスが、その米国をエスケープした文字が交換された場合に変化した場合に予約されています-ASCIIエンコーディング」[12]。
SIP-URL = "sip:" [ userinfo "@" ] hostport url-parameters [ headers ] userinfo = user [ ":" password ] user = *( unreserved | escaped | "&" | "=" | "+" | "$" | "," ) password = *( unreserved | escaped | "&" | "=" | "+" | "$" | "," ) hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit url-parameters = *( ";" url-parameter ) url-parameter = transport-param | user-param | method-param | ttl-param | maddr-param | other-param transport-param = "transport=" ( "udp" | "tcp" ) ttl-param = "ttl=" ttl ttl = 1*3DIGIT ; 0 to 255 maddr-param = "maddr=" host user-param = "user=" ( "phone" | "ip" ) method-param = "method=" Method tag-param = "tag=" UUID UUID = 1*( hex | "-" ) other-param = ( token | ( token "=" ( token | quoted-string ))) headers = "?" header *( "&" header ) header = hname "=" hvalue hname = 1*uric hvalue = *uric uric = reserved | unreserved | escaped reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," digits = 1*DIGIT
SIP-URL = "SIP：" [userinfoを "@"]ホスト側のURLパラメータ[ヘッダ]のuserinfo =ユーザー[ "：" パスワード]ユーザー= *（予約されていない|エスケープ| "＆" | "=" | "+" | "$" | ""）パスワード= *（未予約|エスケープ| "＆" | "=" | "+" | "$" | ""）のHostPort =ホスト[ "：" ポート]ホスト=ホスト名| IPv4Addressをホスト名= *（domainlabel ""）toplabelの[ "" ] domainlabel = alphanum | alphanum *（alphanum | " - "）alphanum toplabel =アルファ|アルファ*（alphanum | " - "）alphanum IPv4Addressを= 1 *数字 "" 1 *数字 "" 1 *数字 "" 1 * 2桁のポート= *桁のURLパラメータ= *（ ";" URLパラメータ）URLパラメータ=輸送-PARAM |ユーザーPARAM |方法-PARAM | TTL-PARAM | MADDR-PARAM |他の-のparam輸送-PARAM = "トランスポート="（ "UDP" | "TCP"）TTL-PARAM = "TTL =" のTTL、TTL = 1 * 3DIGIT。 0〜255 MADDR-PARAM = "MADDR =" ホストユーザPARAM = "ユーザ="（ "電話" | "IP"）メソッドPARAM = "METHOD =" メソッドタグPARAM = "タグ=" UUID UUID = 1 *（16進| " - "）他の-PARAM =（トークン|（トークン "="（トークン|引用符で囲まれた文字列）））ヘッダ= "？"ヘッダ予約*（ "＆" ヘッダ）ヘッダ= hname "=" hvalue hname = 1 *尿hvalue = *尿の尿= |予約されていません| 「;」=予約エスケープ| "/" | "？" | "：" | "@" | "＆" | "=" | "+" | "$" | "" 数字= 1 * DIGIT
Figure 3: SIP URL syntax
図3：SIP URL構文
The URI character classes referenced above are described in Appendix C.
上記に参照URIの文字クラスは、付録Cで説明されています
The components of the SIP URI have the following meanings.
SIP URIのコンポーネントには以下の意味を有します。
telephone-subscriber = global-phone-number | local-phone-number global-phone-number = "+" 1*phonedigit [isdn-subaddress] [post-dial] local-phone-number = 1*(phonedigit | dtmf-digit | pause-character) [isdn-subaddress] [post-dial] isdn-subaddress = ";isub=" 1*phonedigit post-dial = ";postd=" 1*(phonedigit | dtmf-digit | pause-character) phonedigit = DIGIT | visual-separator visual-separator = "-" | "." pause-character = one-second-pause | wait-for-dial-tone one-second-pause = "p" wait-for-dial-tone = "w" dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
電話加入者=グローバル・電話番号|ローカル・電話番号グローバル・電話番号= "+" 1 * phonedigit [ISDNサブアドレス] [ポストダイヤル]ローカルの電話番号= 1 *（phonedigit | DTMF桁|一時停止文字）[ISDN-サブアドレス] [ポストダイヤル] ISDNサブアドレス= "; Isubは=" 1 * phonedigitポストダイヤル= "; postd =" 1 *（phonedigit | DTMF桁|一時停止文字）phonedigit = DIGIT |視覚的な区切りビジュアル区切り=「 - 」| ""一時停止文字= 1秒休止|待ちダイヤルトーン1秒ポーズは=「P」待ちダイヤルトーン=「w」のDTMF桁=「*」| "＃" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber
図4：SIP URL構文。電話加入者
user: If the host is an Internet telephony gateway, the user field MAY also encode a telephone number using the notation of telephone-subscriber (Fig. 4). The telephone number is a special case of a user name and cannot be distinguished by a BNF. Thus, a URL parameter, user, is added to distinguish telephone numbers from user names. The phone identifier is to be used when connecting to a telephony gateway. Even without this parameter, recipients of SIP URLs MAY interpret the pre-@ part as a phone number if local restrictions on the name space for user name allow it.
ユーザー：ホストがインターネット電話ゲートウェイである場合、ユーザフィールドは、電話加入者（図4）の表記法を使用して、電話番号を符号化することができます。電話番号は、ユーザ名の特殊なケースであるとBNFで区別することはできません。このように、URLパラメータ、ユーザーは、ユーザー名から電話番号を区別するために追加されます。電話識別子は、電話ゲートウェイに接続するときに使用されます。ユーザー名のネームスペース上のローカル制約がそれを許可している場合でも、このパラメータを指定せずに、SIP URLの受信者は、電話番号など事前@部分を解釈するかもしれません。
password: The SIP scheme MAY use the format "user:password" in the userinfo field. The use of passwords in the userinfo 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.
パスワード：のUserInfoフィールドには：「パスワードユーザー」SIP方式はフォーマットを使用するかもしれません。 （URIなど）クリアテキストでの認証情報の受け渡しは、それが使用されているほぼすべてのケースではセキュリティ上のリスクがあることが証明されているので、userinfoを内のパスワードの使用は、推奨されません。
host: The mailto: URL and RFC 822 email addresses require that numeric host addresses ("host numbers") are enclosed in square brackets (presumably, since host names might be numeric), while host numbers without brackets are used for all other URLs. The SIP URL requires the latter form, without brackets.
ホスト：MAILTO：URLおよびRFC 822の電子メールアドレスは、数値のホストアドレス（「ホスト番号」）は角括弧で囲まれていることが必要です（おそらく、ホスト名が数値であるかもしれないので）、括弧なしのホスト番号が他のすべてのURLに使用されています。 SIP URLは括弧なしで、後者の形式を必要とします。
The issue of IPv6 literal addresses in URLs is being looked at elsewhere in the IETF. SIP implementers are advised to keep up to date on that activity.
URLでのIPv6のリテラルアドレスの問題は、他の場所IETFで見られています。 SIPの実装者は、その活動を最新に保つことをお勧めします。
port: The port number to send a request to. If not present, the procedures outlined in Section 1.4.2 are used to determine the port number to send a request to.
ポート：に要求を送信するポート番号。存在しない場合は、セクション1.4.2に概説された手順は、に要求を送信するポート番号を決定するために使用されます。
URL parameters: SIP URLs can define specific parameters of the request. URL parameters are added after the host component and are separated by semi-colons. The transport parameter determines the the transport mechanism (UDP or TCP). UDP is to be assumed when no explicit transport parameter is included. The maddr parameter provides the server address to be contacted for this user, overriding the address supplied in the host field. This address is typically a multicast address, but could also be the address of a backup server. 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. The user parameter was described above. For example, to specify to call j.doe@big.com using multicast to 239.255.255.1 with a ttl of 15, the following URL would be used:
URLパラメータ：SIP URLはリクエストの特定のパラメータを定義することができます。 URLパラメータは、ホストコンポーネントの後に添加し、セミコロンによって分離されています。輸送パラメータは、トランスポートメカニズム（UDPまたはTCP）を決定します。 UDPは、明示的な輸送パラメータが含まれていない場合に想定されます。 MADDRパラメータは、ホストフィールドに供給されたアドレスを優先して、このユーザのために連絡するサーバーアドレスを提供します。このアドレスは、通常、マルチキャストアドレスですが、また、バックアップサーバのアドレスである可能性があります。 TTLパラメータは、UDPマルチキャストパケットの存続時間値を決定し、MADDRがマルチキャストアドレスであり、転送プロトコルがUDPである場合にのみ使用されなければなりません。ユーザパラメータは、上述しました。例えば、15のTTLと239.255.255.1するマルチキャストを使用してj.doe@big.com呼び出すために指定するには、以下のURLを使用することになります。
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
SIP：j.doe@big.com; MADDR = 239.255.255.1; TTL = 15
The transport, maddr, and ttl parameters MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present.
輸送、MADDR、およびTTLパラメータは、FromおよびフィールドとRequest-URIヘッダに使用してはいけません。存在する場合、それらは無視されます。
Headers: Headers of the SIP request can be defined with the "?" mechanism within a SIP URL. The special hname "body" indicates that the associated hvalue is the message-body of the SIP INVITE request. Headers MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present. hname and hvalue are encodings of a SIP header name and value, respectively. All URL reserved characters in the header names and values MUST be escaped.
ヘッダ：「？」SIPリクエストのヘッダーを使用して定義することができますSIP URL内のメカニズム。特別hname「本体」は関連hvalueは、SIPのメッセージ本体がINVITE要求であることを示しています。ヘッダーからとフィールドとRequest-URIヘッダに使用してはいけません。存在する場合、それらは無視されます。 hnameとhvalueは、それぞれ、SIPヘッダの名前と値の符号化です。ヘッダの名前と値のすべてのURL予約文字をエスケープする必要があります。
Method: The method of the SIP request can be specified with the method parameter. This parameter MUST NOT be used in the From and To header fields and the Request-URI; they are ignored if present.
方法：SIPリクエストのメソッドは、メソッドのパラメータで指定することができます。このパラメータは、FromおよびフィールドとRequest-URIヘッダに使用してはいけません。存在する場合、それらは無視されます。
Table 2 summarizes where the components of the SIP URL can be used and what default values they assume if not present.
SIP URLのコンポーネントを使用することができ、存在しない場合、彼らは仮定何デフォルト値はどこ表2にまとめました。
Examples of SIP URLs are:
SIP URLの例は次の通りであります：
default Req.-URI To From Contact external user -- x x x x x password -- x x x x host mandatory x x x x x port 5060 x x x x x user-param ip x x x x x method INVITE x x maddr-param -- x x ttl-param 1 x x transp.-param -- x x headers -- x x
xxxxxはパスワード - - 必須xxxxxはポート5060 xxxxxはユーザーのparamのIP XXXXX方法はXX MADDR-PARAMをINVITEホストxxxxは - XX TTL-PARAM 1 XX transp.-PARAM - XXヘッダ連絡先、外部ユーザーからデフォルトReq.-URIへ - XX
Table 2: Use and default values of URL components for SIP headers, Request-URI and references
表2：使用してSIPヘッダのURLのコンポーネントのデフォルト値、リクエスト-URIと参照
sip:j.doe@big.com sip:j.doe:secret@big.com;transport=tcp sip:j.doe@big.com?subject=project sip:+1-212-555-1212:1234@gateway.com;user=phone sip:1212@gateway.com sip:alice@10.1.2.3 sip:alice@example.com sip:alice%40example.com@gateway.com sip:alice@registrar.com;method=REGISTER
SIP：SIP j.doe@big.com：j.doe：secret@big.com;輸送= TCPのSIP：？j.doe@big.com対象=プロジェクトSIP：+ 1-212-555-1212：1234 @ gateway.com;ユーザー=電話SIP：1212@gateway.com SIP：alice@10.1.2.3のSIP：alice@example.com SIP：alice%40example.com@gateway.com SIP：alice@registrar.com;メソッド= REGISTER
Within a SIP message, URLs are used to indicate the source and intended destination of a request, redirection addresses and the current destination of a request. Normally all these fields will contain SIP URLs.
SIPメッセージ内に、URLがソースと要求、リダイレクトアドレスと要求の現在の宛先の意図された宛先を示すために使用されます。通常、すべてのこれらのフィールドは、SIPのURLが含まれています。
SIP URLs are case-insensitive, so that for example the two URLs sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All URL parameters are included when comparing SIP URLs for equality.
j.doe@example.comとSIP：J.Doe@Example.com同等である2つのURLのSIP例えばようにSIP URLは、大文字小文字を区別しています。平等のためのSIP URLを比較するとき、すべてのURLパラメータが含まれています。
SIP header fields MAY contain non-SIP URLs. As an example, if a call from a telephone is relayed to the Internet via SIP, the SIP From header field might contain a phone URL.
SIPヘッダフィールドは、非SIP URLを含むかもしれません。電話からの通話がSIPを介してインターネットに中継される場合の例としては、FromヘッダーフィールドSIPは、電話URLが含まれる場合があります。
3 SIP Message Overview
3 SIPメッセージの概要
SIP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as line terminators.
SIPは、テキストベースのプロトコルであり、UTF-8エンコーディングにISO 10646文字セットを使用する（RFC 2279 [21]）。送信者は、CRLFを持つ行を終了しなければならないが、受信機は、ラインターミネータとして単独でCRとLFを解釈しなければなりません。
Except for the above difference in character sets, much of the message syntax is and header fields are 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 2068 [11]). In addition, we describe SIP in both prose and an augmented Backus-Naur form (ABNF). See section C for an overview of ABNF.
文字セット内の上記差を除いて、メッセージの構文の多くがあり、ヘッダフィールドは、HTTP / 1.1と同一です。むしろ、ここで私たちは現在のHTTP / 1.1仕様（RFC 2068 [11]）のセクションX.Yを参照するために[HX.Y]使用する構文とセマンティクスを繰り返すよりも。加えて、我々は、散文と拡張バッカス・ナウアフォーム（ABNF）の両方でSIPを記述する。 ABNFの概要については、セクションCを参照してください。
Note, however, that SIP is not an extension of HTTP.
SIPはHTTPの拡張ではないこと、しかし、注意してください。
Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP transactions can be carried in a single TCP connection or UDP datagram. UDP datagrams, including all headers, SHOULD NOT be larger than the path maximum transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU is unknown.
HTTPとは異なり、SIPは、UDPを使用するかもしれません。 TCPやUDP経由で送信される場合には、複数のSIPトランザクションは、単一のTCP接続またはUDPデータグラムで行うことができます。 MTUが不明な場合MTUが既知、または1500バイトであれば、すべてのヘッダを含むUDPデータグラムは、パスの最大伝送単位（MTU）よりも大きくすべきではありません。
The 1500 bytes accommodates encapsulation within the
"typical" ethernet MTU without IP fragmentation. Recent
studies [22] indicate that an MTU of 1500 bytes is a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
[23]). Thus, another reasonable value would be a message
size of 950 bytes, to accommodate packet headers within the
SLIP MTU without fragmentation.
A SIP message is either a request from a client to a server, or a response from a server to a client.
SIPメッセージは、クライアントからサーバへの要求、またはサーバからクライアントへの応答のいずれかです。
SIP-message = Request | Response
SIPメッセージ=リクエスト|応答
Both Request (section 4) and Response (section 5) messages use the generic-message format of RFC 822 [24] for transferring entities (the body of the message). Both types of messages consist of a start-line, one or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the carriage-return line-feed (CRLF)) indicating the end of the header fields, and an optional message-body. To avoid confusion with similar-named headers in HTTP, we refer to the headers describing the message body as entity headers. These components are described in detail in the upcoming sections.
両方の要求（セクション4）と応答（セクション5）メッセージは、エンティティを転送する[24] RFC 822の一般的なメッセージフォーマット（メッセージのボディ）を使用します。メッセージの両方のタイプは、スタートライン、（また、「ヘッダー」としても知られる）は、1つ以上のヘッダフィールド、終了を示す空行（すなわち、キャリッジリターンラインフィード（CRLF）の前に何もない行）で構成しますヘッダフィールド、およびオプションのメッセージボディの。 HTTPでの類似した名前のヘッダとの混同を避けるために、我々は、エンティティヘッダーとしてメッセージ本体を記述するヘッダを参照してください。これらのコンポーネントは、今後のセクションで詳細に説明されています。
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | ;Section 4.1 Status-Line ;Section 5.1
=リクエストラインラインを開始| ;セクション4.1ステータスライン;セクション5.1
message-header = ( general-header | request-header | response-header | entity-header )
メッセージヘッダー=（一般ヘッダー|要求ヘッダー|応答ヘッダ|エンティティヘッダ）
In the interest of robustness, any leading empty line(s) MUST be ignored. In other words, if the Request or Response message begins with one or more CRLF, CR, or LFs, these characters MUST be ignored.
ロバスト性の利益のために、先頭の空白行（複数可）は無視しなければなりません。言い換えれば、要求または応答メッセージは、1つまたは複数のCRLF、CR、またはのLFで始まる場合、これらの文字は無視しなければなりません。
4 Request
4リクエスト
The Request message format is shown below:
要求メッセージのフォーマットを以下に示します。
Request = Request-Line ; Section 4.1
*( general-header
| request-header
| entity-header )
CRLF
[ message-body ] ; Section 8
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence.
リクエストラインは、Request-URIとプロトコルバージョンが続き、CRLFで終わる、メソッドトークンで始まります。要素はSP文字で区切られます。いいえCRやLFは、最終的なCRLFシーケンス以外で許可されません。
Request-Line = Method SP Request-URI SP SIP-Version CRLF general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Call-ID ; Section 6.12
| Contact ; Section 6.13
| CSeq ; Section 6.17
| Date ; Section 6.18
| Encryption ; Section 6.19
| Expires ; Section 6.20
| From ; Section 6.21
| Record-Route ; Section 6.29
| Timestamp ; Section 6.36
| To ; Section 6.37
| Via ; Section 6.40
entity-header = Content-Encoding ; Section 6.14
| Content-Length ; Section 6.15
| Content-Type ; Section 6.16
request-header = Authorization ; Section 6.11
| Contact ; Section 6.13
| Hide ; Section 6.22
| Max-Forwards ; Section 6.23
| Organization ; Section 6.24
| Priority ; Section 6.25
| Proxy-Authorization ; Section 6.27
| Proxy-Require ; Section 6.28
| Route ; Section 6.33
| Require ; Section 6.30
| Response-Key ; Section 6.31
| Subject ; Section 6.35
| User-Agent ; Section 6.39
response-header = Allow ; Section 6.10
| Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32
| Server ; Section 6.34
| Unsupported ; Section 6.38
| Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42
Table 3: SIP headers
表3：SIPヘッダー
The methods are defined below. Methods that are not supported by a proxy or redirect server are treated by that server as if they were an OPTIONS method and forwarded accordingly. Methods that are not supported by a user agent server or registrar cause a 501 (Not Implemented) response to be returned (Section 7). As in HTTP, the Method token is case-sensitive.
方法は、以下に定義されています。それらはOPTIONSメソッドであり、それに応じて転送する場合のように、プロキシによってサポートされているか、サーバリダイレクトされない方法は、そのサーバーによって処理されます。ユーザエージェントサーバやレジストラでサポートされていないメソッドが返される501（実装されていない）応答（第7節）を引き起こします。 HTTPと同様に、メソッドトークンは、大文字と小文字が区別されます。
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "CANCEL" | "REGISTER"
The INVITE method indicates that the user or service is being invited to participate in a session. The message body contains a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive and possibly the media it is willing to send as well as their parameters such as network destination. A success response MUST indicate in its message body which media the callee wishes to receive and MAY indicate the media the callee is going to send.
INVITEメソッドは、ユーザーまたはサービスがセッションに参加するよう招待されていることを示しています。メッセージ本文には、呼び出し先が招待されているために、セッションの記述が含まれています。 2パーティコールの場合、呼び出し側は、受信すると、おそらくそれは喜んでいるメディアは、ネットワーク先としてそれらのパラメータだけでなく、送信することが可能であるメディアの種類を示します。成功応答は、呼び出し先が受信したいと呼び出し先が送信しようとしているメディアを示している可能性があり、メディアにそのメッセージ本文に指定する必要があります。
Not all session description formats have the ability to
indicate sending media.
A server MAY automatically respond to an invitation for a conference the user is already participating in, identified either by the SIP Call-ID or a globally unique identifier within the session description, with a 200 (OK) response.
サーバが自動的にユーザーが既に200（OK）応答で、いずれかのSIPコールIDまたはセッション記述内でグローバルに一意の識別子によって識別され、中に参加している会議の招待状に応答することができます。
If a user agent receives an INVITE request for an existing call leg with a higher CSeq sequence number than any previous INVITE for the same Call-ID, 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. It MUST also inspect any other header fields for changes. If there is a change, the user agent MUST update any internal state or information generated as a result of that header. If the session description has changed, the user agent server MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. (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.)
ユーザエージェントは、同じCall-IDのためのINVITE以前よりも高いのCSeqシーケンス番号を持つ既存のコールレッグのINVITEリクエストを受信した場合、それは、何のバージョン識別子が存在しない場合、セッション記述のいずれかのバージョン識別子をチェックしたりしなければなりませんそれが変更されているかどうかを確認するためにセッション記述の内容。それはまた、変更するための任意の他のヘッダフィールドを検査しなければなりません。変更がある場合、ユーザーエージェントは、そのヘッダの結果として生成された内部状態や情報を更新する必要があります。セッション記述が変更された場合、ユーザエージェントサーバは、おそらくユーザーに確認を求めた後、それに応じてセッションパラメータを調整する必要があります。 （セッション記述のバージョンは、メディアまたはマルチキャスト会議へのユニキャストからの変化を、会議に新着の機能を収容する追加または削除するために使用することができます。）
This method MUST be supported by SIP proxy, redirect and user agent servers as well as clients.
この方法では、エージェントサーバと同様にクライアントをリダイレクトし、ユーザー、SIPプロキシによってサポートしなければなりません。
The ACK request confirms that the client has received a final response to an INVITE request. (ACK is used only with INVITE requests.) 2xx responses are acknowledged by client user agents, all other final responses by the first proxy or client user agent to receive the response. The Via is always initialized to the host that originates the ACK request, i.e., the client user agent after a 2xx response or the first proxy to receive a non-2xx final response. The ACK request is forwarded as the corresponding INVITE request, based on its Request-URI. See Section 10 for details.
ACK要求は、クライアントがINVITE要求に対する最終応答を受信したことを確認します。 （ACKのみINVITE要求に使用される。）の2xx応答が最初のプロキシまたはクライアントのユーザエージェントによって他のすべての最終応答が応答を受信するために、クライアントのユーザエージェントによって認められています。ビアは常に2xx応答または非2xxの最終的な応答を受信するための最初のプロキシ後にACK要求、すなわち、クライアントのユーザーエージェントを発信ホストに初期化されます。 ACK要求は、その要求URIに基づいて、INVITE要求に対応するように転送されます。詳細については、セクション10を参照してください。
The ACK request MAY contain a message body with the final session description to be used by the callee. If the ACK message body is empty, the callee uses the session description in the INVITE request.
ACK要求が被呼者によって使用される最終的なセッション記述とメッセージ本体を含むかもしれません。 ACKメッセージの本文が空の場合、着呼側は、INVITE要求にセッション記述を使用します。
A proxy server receiving an ACK request after having sent a 3xx, 4xx, 5xx, or 6xx response must make a determination about whether the ACK is for it, or for some user agent or proxy server further downstream. This determination is made by examining the tag in the To field. If the tag in the ACK To header field matches the tag in the To header field of the response, and the From, CSeq and Call-ID header fields in the response match those in the ACK, the ACK is meant for the proxy server. Otherwise, the ACK SHOULD be proxied downstream as any other request.
プロキシ3XXを送信した後にACK要求を受信したサーバ、4xx、5xx、または6xx応答は、ACKがそれのために、またはいくつかのユーザエージェントまたはプロキシサーバに対してさらに下流にあるかどうかについての決意をしなければなりません。この決意は、Toフィールドにタグを調べることによって行われます。 ToヘッダーフィールドACKでタグが応答のToヘッダーフィールド内のタグにマッチし、それに応答してのCSeqおよびCall-IDヘッダフィールドは、ACKのものと一致し、から、ACKは、プロキシサーバのために意味されている場合。それ以外の場合、ACKは、他の要求として下流プロキシされるべきです。
It is possible for a user agent client or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to a
request along a single branch. This can happen under
various error conditions, typically when a forking proxy
transitions from stateful to stateless before receiving all
responses. The various responses will all be identical,
except for the tag in the To field, which is different for
each one. It can therefore be used as a means to
disambiguate them.
This method MUST be supported by SIP proxy, redirect and user agent servers as well as clients.
この方法では、エージェントサーバと同様にクライアントをリダイレクトし、ユーザー、SIPプロキシによってサポートしなければなりません。
The server is being queried as to its capabilities. A server that believes it can contact the user, such as a user agent where the user is logged in and has been recently active, MAY respond to this request with a capability set. A called user agent MAY return a status reflecting how it would have responded to an invitation, e.g.,
サーバーは、その機能にとして照会されます。それは、このようなユーザーがログインしているし、最近活動している、能力セットでこの要求に応答することができるユーザエージェントとして、利用者に連絡することができます信じているサーバー。呼ばれるユーザーエージェントは、例えば、それは招待に応えてきただろうか反映した状態を返してもよい（MAY）
600 (Busy). Such a server SHOULD return an Allow header field indicating the methods that it supports. Proxy and redirect servers simply forward the request without indicating their capabilities.
600（BUSY）。そのようなサーバは、それがサポートする方法を示すヘッダフィールドを許可し返すべきです。プロキシとリダイレクトサーバーは、単に自分の能力を示すことなく、要求を転送します。
This method MUST be supported by SIP proxy, redirect and user agent servers, registrars and clients.
この方法では、エージェント・サーバ、レジストラとクライアントをリダイレクトし、ユーザー、SIPプロキシによってサポートしなければなりません。
The user agent client uses BYE to indicate to the server that it wishes to release the call. A BYE request is forwarded like an INVITE request and MAY be issued by either caller or callee. A party to a call SHOULD issue a BYE request before releasing a call ("hanging up"). A party receiving a BYE request MUST cease transmitting media streams specifically directed at the party issuing the BYE request.
ユーザエージェントクライアントは、それがコールを解放したいサーバーに示すためにBYEを使用しています。 BYE要求は、INVITEリクエストのように転送され、発信者または呼び出し先のいずれかによって発行することができます。コールの当事者は、コール（「ハングアップ」）をリリースする前にBYE要求を発行する必要があります。 BYE要求を受信した当事者は、具体的にBYE要求を発行する当事者に向けメディアストリームを送信することを中止しなければなりません。
If the INVITE request contained a Contact header, the callee SHOULD send a BYE request to that address rather than the From address.
INVITEリクエストがContactヘッダーが含まれていた場合、呼び出し先はそのアドレスではなく、FromアドレスにBYE要求を送るべきです。
This method MUST be supported by proxy servers and SHOULD be supported by redirect and user agent SIP servers.
このメソッドは、プロキシサーバでサポートしなければならないとリダイレクトとユーザーエージェントSIPサーバによってサポートされる必要があります。
The CANCEL request cancels a pending request with the same Call-ID, To, From and CSeq (sequence number only) header field values, but does not affect a completed request. (A request is considered completed if the server has returned a final status response.)
CANCEL要求は、同じCall-ID、に、よりとのCSeq（シーケンス番号のみ）ヘッダフィールド値を持つ保留中の要求をキャンセルしたが、完了した要求に影響を及ぼしません。 （サーバが最終ステータス応答を返した場合、要求が完了したとみなされます。）
A user agent client or proxy client MAY issue a CANCEL request at any time. A proxy, in particular, MAY choose to send a CANCEL to destinations that have not yet returned a final response after it has received a 2xx or 6xx response for one or more of the parallel-search requests. A proxy that receives a CANCEL request forwards the request to all destinations with pending requests.
ユーザエージェントクライアントまたはプロキシクライアントは、いつでもCANCELリクエストを発行することができます。プロキシは、特に、それが並列検索要求の1以上の2xxまたは6xxの応答を受信した後に、まだ最終的な応答を返されていない宛先にCANCELを送信するために選ぶかもしれません。 CANCELリクエストを受け取るプロキシが保留中の要求を持つすべての宛先に要求を転送します。
The Call-ID, To, the numeric part of CSeq and From headers in the CANCEL request are identical to those in the original request. This allows a CANCEL request to be matched with the request it cancels. However, to allow the client to distinguish responses to the CANCEL from those to the original request, the CSeq Method component is set to CANCEL. The Via header field is initialized to the proxy issuing the CANCEL request. (Thus, responses to this CANCEL request only reach the issuing proxy.)
コールID、へ、のCSeqの数字の一部とCANCEL要求におけるFromヘッダーは、元の要求と同一です。これは、CANCEL要求は、それが取り消し要求と一致することができます。しかし、クライアントは元の要求にそれらからCANCELへの応答を区別できるようにするために、のCSeqメソッドコンポーネントはCANCELに設定されています。 Viaヘッダーフィールドは、CANCELリクエストを発行するプロキシに初期化されます。 （したがって、このCANCELリクエストへの応答が唯一の発行プロキシに達します。）
Once a user agent server has received a CANCEL, it MUST NOT issue a 2xx response for the cancelled original request.
ユーザエージェントサーバは、CANCEL受信したら、それは取り消され、元の要求に対する2xx応答を発行してはいけません。
A redirect or user agent server receiving a CANCEL request responds with a status of 200 (OK) if the transaction exists and a status of 481 (Transaction Does Not Exist) if not, but takes no further action. In particular, any existing call is unaffected.
CANCEL要求を受信し、リダイレクトやユーザエージェントサーバは、トランザクションが存在する場合、200のステータス（OK）で応答し、481の状態（トランザクションが存在しない）でない場合は、しかし、以降のアクションを実行しません。具体的には、既存のコールは影響を受けません。
The BYE request cannot be used to cancel branches of a
parallel search, since several branches may, through
intermediate proxies, find the same user agent server and
then terminate the call. To terminate a call instead of
just pending searches, the UAC must use BYE instead of or
in addition to CANCEL. While CANCEL can terminate any
pending request other than ACK or CANCEL, it is typically
useful only for INVITE. 200 responses to INVITE and 200
responses to CANCEL are distinguished by the method in the
Cseq header field, so there is no ambiguity.
This method MUST be supported by proxy servers and SHOULD be supported by all other SIP server types.
このメソッドは、プロキシサーバでサポートしなければならないし、他のすべてのSIPサーバの種類によってサポートされる必要があります。
A client uses the REGISTER method to register the address listed in the To header field with a SIP server.
クライアントは、SIPサーバとのフィールドをヘッダに記載されているアドレスを登録するREGISTERメソッドを使用します。
A user agent MAY register with a local server on startup by sending a REGISTER request to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. This MAY be done with either TTL or administrative scopes [25], depending on what is implemented in the network. SIP user agents MAY listen to that address and use it to become aware of the location of other local users [20]; however, they do not respond to the request. A user agent MAY also be configured with the address of a registrar server to which it sends a REGISTER request upon startup.
ユーザーエージェントは、よく知られた「すべてのSIPサーバ」マルチキャストアドレス「sip.mcast.net」（224.0.1.75）にREGISTERリクエストを送信することにより、起動時にローカルサーバーに登録することができます。この要求は、それが行政システムの境界を越えて転送されていないことを確認するためにスコープされるべきである（SHOULD）。これは、ネットワークに実装されているものに応じて、[25] TTLまたは管理スコープのいずれかで行うことができます。 SIPユーザエージェントは、そのアドレスをリッスンし、他のローカルユーザ[20]の位置を自覚するためにそれを使用することができます。しかし、彼らは要求に応答しません。ユーザエージェントはまた、起動時にREGISTERリクエストを送信するにレジストラサーバのアドレスを用いて構成することができます。
Requests are processed in the order received. Clients SHOULD avoid sending a new registration (as opposed to a retransmission) until they have received the response from the server for the previous one.
リクエストは受け付け順に処理されます。クライアントは、以前のもののためにサーバからの応答を受け取るまで（再送信ではなく）新規登録を送ることは避けるべきです。
Clients may register from different locations, by necessity
using different Call-ID values. Thus, the CSeq value cannot
be used to enforce ordering. Since registrations are
additive, ordering is less of a problem than if each
REGISTER request completely replaced all earlier ones.
The meaning of the REGISTER request-header fields is defined as follows. We define "address-of-record" as the SIP address that the registry knows the registrand, typically of the form "user@domain" rather than "user@host". In third-party registration, the entity issuing the request is different from the entity being registered.
次のようにREGISTERリクエスト・ヘッダー・フィールドの意味は定義されています。私たちは、「アドレスのレコード」レジストリは通常はフォーム「ユーザー@ドメイン」ではなく「ユーザー@ホスト」の、registrandを知っているSIPアドレスなどを定義します。サードパーティの登録では、要求を発行するエンティティは、登録されたエンティティとは異なります。
To: The To header field contains the address-of-record whose registration is to be created or updated.
To：Toヘッダーフィールドを持つ登録作成または更新されるアドレスのレコードが含まれています。
From: The From header field contains the address-of-record of the person responsible for the registration. For first-party registration, it is identical to the To header field value.
From：Fromヘッダフィールドアドレス・オブ・レコードの登録のための責任者の含まれています。ファーストパーティの登録の場合は、フィールドの値をToヘッダーと同じです。
Request-URI: The Request-URI names the destination of the registration request, i.e., the domain of the registrar. The user name MUST be empty. Generally, the domains in the Request-URI and the To header field have the same value; however, it is possible to register as a "visitor", while maintaining one's name. For example, a traveler sip:alice@acme.com (To) might register under the Request-URI sip:atlanta.hiayh.org , with the former as the To header field and the latter as the Request-URI. The REGISTER request is no longer forwarded once it has reached the server whose authoritative domain is the one listed in the Request-URI.
リクエストURI：リクエストURI名前登録要求、つまり、レジストラのドメインの宛先。ユーザー名は空でなければなりません。一般に、リクエストURIおよびToヘッダーフィールド内のドメインは、同じ値を有します。しかし、自分の名前を維持しながら、「訪問者」として登録することが可能です。例えば、ユーザーのSIP：フィールドとRequest-URIとして、後者をToヘッダとして前者と、atlanta.hiayh.org：alice@acme.com（TO）は、要求URIのSIPの下で登録することがあります。それはその権限のあるドメインのRequest-URIに記載されているものですサーバーに達するとREGISTERリクエストは、もはや転送されません。
Call-ID: All registrations from a client SHOULD use the same Call-ID header value, at least within the same reboot cycle.
コールIDを：クライアントからのすべての登録は、少なくとも同じリブートサイクル内で、同じCall-IDヘッダーの値を使用する必要があります。
Cseq: Registrations with the same Call-ID MUST have increasing CSeq header values. However, the server does not reject out-of-order requests.
CSEQ：同じCall-IDを持つ登録が増加CSeqヘッダーの値を持たなければなりません。ただし、サーバーは、アウト・オブ・オーダー要求を拒否しません。
Contact: The request MAY contain a Contact header field; future non-REGISTER requests for the URI given in the To header field SHOULD be directed to the address(es) given in the Contact header.
問い合わせ先：リクエストがContactヘッダーフィールドを含む可能性があります。 Toヘッダフィールドに指定されたURIのための将来の非REGISTER要求は、Contactヘッダに指定されたアドレス（ES）に向けられるべきです。
If the request does not contain a Contact header, the registration remains unchanged.
リクエストがContactヘッダーが含まれていない場合、登録は変わりません。
This is useful to obtain the current list of registrations
in the response. Registrations using SIP URIs that differ
in one or more of host, port, transport-param or maddr-
param (see Figure 3) from an existing registration are
added to the list of registrations. Other URI types are
compared according to the standard URI equivalency rules
for the URI schema. If the URIs are equivalent to that of
an existing registration, the new registration replaces the old one if it has a higher q value or, for the same value
of q, if the ttl value is higher. All current registrations
MUST share the same action value. Registrations that have
a different action than current registrations for the same
user MUST be rejected with status of 409 (Conflict).
A proxy server ignores the q parameter when processing non-REGISTER requests, while a redirect server simply returns that parameter in its Contact response header field.
リダイレクトサーバーは、単にその連絡レスポンスヘッダフィールドにそのパラメータを返しながら、非REGISTERリクエストを処理する際、プロキシサーバは、qパラメータを無視します。
Having the proxy server interpret the q parameter is not
sufficient to guide proxy behavior, as it is not clear, for
example, how long it is supposed to wait between trying
addresses.
If the registration is changed while a user agent or proxy server processes an invitation, the new information SHOULD be used.
登録が変更された場合、ユーザエージェントまたはプロキシサーバが招待を処理している間、新たな情報が使用されるべきです。
This allows a service known as "directed pick-up". In the
telephone network, directed pickup permits a user at a
remote station who hears his own phone ringing to pick up
at that station, dial an access code, and be connected to
the calling user as if he had answered his own phone.
A server MAY choose any duration for the registration lifetime. Registrations not refreshed after this amount of time SHOULD be silently discarded. Responses to a registration SHOULD include an Expires header (Section 6.20) or expires Contact parameters (Section 6.13), indicating the time at which the server will drop the registration. If none is present, one hour is assumed. Clients MAY request a registration lifetime by indicating the time in an Expires header in the request. A server SHOULD NOT use a higher lifetime than the one requested, but MAY use a lower one. A single address (if host-independent) MAY be registered from several different clients.
サーバーは、登録の有効期間のための任意の期間を選択することができます。この時間は静かに捨てられるべきである後に登録が更新されません。登録への応答は、ヘッダ（セクション6.20の）有効期限またはサーバが登録をドロップする時間を示す接触パラメータ（セクション6.13）、期限切れに含まれるべきです。何も存在しない場合は、1時間を想定しています。クライアントは、リクエストにExpiresヘッダの時間を示すことによって、登録寿命を要求することができます。サーバーは、要求されたものより高い生涯を使用するべきではありませんが、下の1つを使用することができます。単一のアドレスは（ホストに依存している場合）、いくつかの異なるクライアントから登録することも可能です。
A client cancels an existing registration by sending a REGISTER request with an expiration time (Expires) of zero seconds for a particular Contact or the wildcard Contact designated by a "*" for all registrations. Registrations are matched based on the user, host, port and maddr parameters.
クライアントは、特定の連絡先またはすべての登録のための「*」で指定されたワイルドカードの接触のために0秒の有効期限（有効期限）とのREGISTERリクエストを送信することにより、既存の登録を取り消します。登録は、ユーザ、ホスト、ポート、およびMADDRパラメータに基づいて、一致しています。
The server SHOULD return the current list of registrations in the 200 response as Contact header fields.
サーバーは、Contactヘッダーフィールドとして200応答に登録の現在のリストを返すべきです。
It is particularly important that REGISTER requests are authenticated since they allow to redirect future requests (see Section 13.2).
彼らは（第13.2節を参照）、将来の要求をリダイレクトすることができますので、REGISTERリクエストが認証されることが特に重要です。
Beyond its use as a simple location service, this method is
needed if there are several SIP servers on a single host.
In that case, only one of the servers can use the default
port number.
Support of this method is RECOMMENDED.
この方法のサポートが推奨されます。
The Request-URI is a SIP URL as described in Section 2 or a general URI. It indicates the user or service to which this request is being addressed. Unlike the To field, the Request-URI MAY be re-written by proxies.
セクション2または一般的なURIに記載されているようにRequest-URIがSIP URLです。これは、この要求が対処されている先のユーザまたはサービスを示します。 Toフィールドとは異なり、Request-URIがプロキシによって再書き込むことができます。
When used as a Request-URI, a SIP-URL MUST NOT contain the transport-param, maddr-param, ttl-param, or headers elements. A server that receives a SIP-URL with these elements removes them before further processing.
要求URIとして使用する場合、SIP-URLは、輸送-PARAM、MADDR-PARAM、TTL-PARAM、またはヘッダ要素を含めることはできません。これらの要素とのSIP-URLを受信するサーバーは、さらに処理する前にそれらを削除します。
Typically, the UAC sets the Request-URI and To to the same
SIP URL, presumed to remain unchanged over long time
periods. However, if the UAC has cached a more direct path
to the callee, e.g., from the Contact header field of a
response to a previous request, the To would still contain
the long-term, "public" address, while the Request-URI
would be set to the cached address.
Proxy and redirect servers MAY use the information in the Request-URI and request header fields to handle the request and possibly rewrite the Request-URI. For example, a request addressed to the generic address sip:sales@acme.com is proxied to the particular person, e.g., sip:bob@ny.acme.com , with the To field remaining as sip:sales@acme.com. At ny.acme.com , Bob then designates Alice as the temporary substitute.
プロキシとリダイレクトサーバーは、要求を処理し、可能性のRequest-URIを書き換えるためのRequest-URIとリクエストヘッダフィールドに情報を使用することができます。例えば、要求は、一般的なSIPアドレス宛て：sales@acme.com：SIP、残りのフィールドにして、bob@ny.acme.com：sales@acme.comは、特定の人物、例えば、SIPにプロキシされます。 ny.acme.comでは、ボブは、一時的な代用としてアリスを指定します。
The host part of the Request-URI typically agrees with one of the host names of the receiving server. If it does not, the server SHOULD proxy the request to the address indicated or return a 404 (Not Found) response if it is unwilling or unable to do so. For example, the Request-URI and server host name can disagree in the case of a firewall proxy that handles outgoing calls. This mode of operation is similar to that of HTTP proxies.
Request-URIのホスト部分は、典型的には、受信側サーバーのホスト名のいずれかと一致します。そうでない場合は、サーバーは、プロキシアドレスへの要求が示されているべきであるか、それは不本意またはそうすることができない場合は404（Not Found）応答を返します。例えば、要求URIとサーバーのホスト名は、発信コールを処理し、ファイアウォール、プロキシの場合には反対することができます。この動作モードは、HTTPプロキシの場合と同様です。
If a SIP server receives a request with a URI indicating a scheme other than SIP which that server does not understand, the server MUST return a 400 (Bad Request) response. It MUST do this even if the To header field contains a scheme it does understand. This is because proxies are responsible for processing the Request-URI; the To field is of end-to-end significance.
SIPサーバは、そのサーバが理解していないSIP以外の方式を示すURIで要求を受信した場合、サーバは400（悪いRequest）応答を返さなければなりません。 Toヘッダーフィールドはそれが理解しない方式を採用していても、それはこの操作を行う必要があります。プロキシが要求URIを処理するための責任があるからです。 Toフィールドには、エンド・ツー・エンドの意義があります。
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".
両方の要求および応答メッセージは、使用中のSIPのバージョンを含み、バージョンの順序付け、コンプライアンス要件、およびバージョン番号のバージョンアップについて（SIPで置き換えHTTP、およびHTTP / 1.1 SIP / 2.0に置き換えで）H3.1]を辿ります。この仕様に準拠するために、SIPメッセージを送信するアプリケーションは、「SIP / 2.0」のSIP-バージョンを含まなければなりません。
Option tags are unique identifiers used to designate new options in SIP. These tags are used in Require (Section 6.30) and Unsupported (Section 6.38) fields.
オプションタグはSIPの新しいオプションを指定するために使用される一意の識別子です。これらのタグは（セクション6.30）およびサポートされていない（セクション6.38）フィールドを要求で使用されています。
Syntax:
構文：
option-tag = token
オプションタグ=トークン
See Section C for a definition of token. The creator of a new SIP option MUST either prefix the option with their reverse domain name or register the new option with the Internet Assigned Numbers Authority (IANA). For example, "com.foo.mynewfeature" is an apt name for a feature whose inventor can be reached at "foo.com". Individual organizations are then responsible for ensuring that option names don't collide. Options registered with IANA have the prefix "org.iana.sip.", options described in RFCs have the prefix "org.ietf.rfc.N", where N is the RFC number. Option tags are case-insensitive.
トークンの定義については、セクションCを参照してください。新しいSIPオプションの作成者は、その逆ドメイン名とオプションの前に付けるか、IANA（Internet Assigned Numbers Authority）によって新しいオプションを登録する必要があります。たとえば、「com.foo.mynewfeatureは」発明「foo.com」に到達することができる機能のaptの名前です。個々の組織は、その後、オプション名が衝突しないことを確実にする責任があります。 IANAに登録されているオプションは、接頭辞「org.iana.sip」を持って、RFCで説明するオプションは、NはRFC番号です接頭辞「org.ietf.rfc.N」を、持っています。オプションタグは大文字と小文字を区別しません。
When registering a new SIP option, the following information MUST be provided:
新しいSIPオプションを登録する場合、以下の情報を提供しなければなりません。
o Name and description of option. The name MAY be of any
length, but SHOULD be no more than twenty characters long. The
name MUST consist of alphanum (See Figure 3) characters only;
o Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium or a particular company or group of companies);
Oオプションの制御を変更する持っている者の指示（例えば、IETF、ISO、ITU-T、他の国際標準化機関、コンソーシアムまたは特定の企業または企業グループ）。
o A reference to a further description, if available, for example (in order of preference) an RFC, a published paper, a patent filing, a technical report, documented source code or a computer manual;
O、利用可能な場合、例えばRFC、発表された論文、特許出願、技術レポート、文書ソースコードまたはコンピュータマニュアル（優先順）さらなる説明を参照します。
o Contact information (postal and email address);
O情報（郵便や電子メールアドレス）にお問い合わせください。
Registrations should be sent to iana@iana.org
登録はiana@iana.orgに送信する必要があります
This procedure has been borrowed from RTSP [4] and the RTP
AVP [26].
5 Response
5レスポンス
After receiving and interpreting a request message, the recipient responds with a SIP response message. The response message format is shown below:
要求メッセージを受信し、解釈した後、受信者はSIP応答メッセージで応答します。応答メッセージのフォーマットを以下に示します。
Response = Status-Line ; Section 5.1
*( general-header
| response-header
| entity-header )
CRLF
[ message-body ] ; Section 8
SIP's structure of responses is similar to [H6], but is defined explicitly here.
応答のSIPの構造は、[H6]に似ていますが、ここで明示的に定義されています。
The first line of a Response message is the Status-Line, consisting of the protocol version (Section 4.3.1) followed by a numeric Status-Code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
応答メッセージの最初の行は、SP文字で区切られた各要素と、数値ステータスコードとそれに関連するテキストフレーズに続くプロトコルバージョン（4.3.1）からなる、ステータスラインです。 CRまたはLF NOが最終のCRLFシーケンス以外で許可されていません。
Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF
ステータスライン= SIP-バージョンSPステータスコードSP理由-フレーズCRLF
The Status-Code is a 3-digit integer result code that indicates the outcome of the attempt to understand and satisfy the 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. The client is not required to examine or display the Reason-Phrase.
ステータスコードを理解し、要求を満たすための試みの結果を示す3桁の整数の結果コードです。理由-フレーズは、ステータスコードの短いテキスト記述を与えることを目的としています。理由-フレーズが人間のユーザのために意図されたのに対し、ステータスコードは、オートマトンによる使用を目的としています。クライアントが理由-フレーズを調べたり、表示するために必要とされていません。
Status-Code = Informational ;Fig. 5
| Success ;Fig. 5
| Redirection ;Fig. 6
| Client-Error ;Fig. 7
| Server-Error ;Fig. 8
| Global-Failure ;Fig. 9
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT-UTF8, excluding CR, LF>
We provide an overview of the Status-Code below, and provide full definitions in Section 7. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. SIP/2.0 allows 6 values for the first digit:
私たちは、7節でステータスコード以下の概要を提供し、完全な定義を提供ステータスコードの最初の数字は応答のクラスを定義します。最後の2桁は任意の分類の役割を持っていません。 SIP / 2.0は、最初の桁6つの値を許可します。
1xx: Informational -- 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;
300番台：リダイレクション - 更なるアクションが要求を完了するために取られる必要があります。
4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
4XX：クライアントエラー - 要求が不正な構文を含む、またはこのサーバーでは実行できません。
5xx: Server Error -- the server failed to fulfill an apparently valid request;
5xxの：サーバーエラー - サーバーが明らかに有効な要求を満たすために失敗しました。
6xx: Global Failure -- the request cannot be fulfilled at any server.
6xx：グローバル失敗 - 要求がどのサーバーでも実行できません。
Figures 5 through 9 present the individual values of the numeric response codes, and an example set of corresponding reason phrases for SIP/2.0. These reason phrases are only recommended; they may be replaced by local equivalents without affecting the protocol. Note that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response codes in the range starting at x80 to avoid conflicts with newly defined HTTP response codes, and adds a new class, 6xx, of response codes.
9本を介して図5の数値応答コードの個々の値、およびSIP / 2.0の対応する理由フレーズのセットの例。これらの理由フレーズのみが推奨されています。彼らは、プロトコルに影響を与えることなく、地元の同等物に置き換えることができます。 SIPは、多くのHTTP / 1.1応答コードを採用していることに注意してください。 SIP / 2.0は、新たに定義されたHTTP応答コードとの競合を避けるために、X80で始まる範囲で応答コードを追加し、応答コードの新しいクラスの6xxを、追加します。
SIP response codes are extensible. SIP applications are not required to understand the meaning of all registered response codes, though such understanding is obviously desirable. However, applications MUST understand the class of any response code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 response code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if a client 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. In such cases, user agents SHOULD present to the user the message body returned with the response, since that message body is likely to include human-readable information which will explain the unusual status.
SIP応答コードは拡張可能です。そのような理解は明らかに望ましいですが、SIPアプリケーションは、登録済みのすべての応答コードの意味を理解する必要はありません。しかし、最初の桁によって示されるように、アプリケーションは、任意の応答コードのクラスを理解しなければならない、と認識されていない応答がキャッシュされてはならないことを除いて、そのクラスのX00の応答コードと等価であると認識されない応答を治療します。たとえば、クライアントが431の認識できない応答コードを受信した場合、それは安全にその要求に何か問題があったと仮定することができますし、それは400（悪いRequest）応答コードを受け取ったかのように応答を扱います。そのメッセージ本体が異常な状態を説明する人間可読情報を含む可能性があるので、このような場合、ユーザエージェントは、メッセージ本体が応答で返さユーザに提示しなければなりません。
Informational = "100" ; Trying
| "180" ; Ringing
| "181" ; Call Is Being Forwarded
| "182" ; Queued
Success = "200" ; OK
Figure 5: Informational and success status codes
図5：情報および成功ステータスコード
Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "305" ; Use Proxy
| "380" ; Alternative Service
Figure 6: Redirection status codes
図6：リダイレクションステータスコード
Client-Error = "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Timeout
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "420" ; Bad Extension
| "480" ; Temporarily not available
| "481" ; Call Leg/Transaction Does Not Exist
| "482" ; Loop Detected
| "483" ; Too Many Hops
| "484" ; Address Incomplete
| "485" ; Ambiguous
| "486" ; Busy Here
Figure 7: Client error status codes
図7：クライアントエラーステータスコード
Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; SIP Version not supported
Figure 8: Server error status codes
図8：サーバーのエラーステータスコード
6 Header Field Definitions
6つのヘッダーフィールドの定義
SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the syntax for message-header as described in [H4.2]. The rules for extending header fields over multiple lines, and use of multiple message-header fields with the same field-name, described in [H4.2] also apply to SIP. The
SIPヘッダフィールドは、構文と意味の両方でHTTPヘッダフィールドに類似しています。 [H4.2]に記載されているように、特に、SIPヘッダフィールドは、メッセージヘッダの構文に従います。 [H4.2]に記載した方法と同じフィールド名を持つ複数のライン上のヘッダフィールドを拡張し、複数のメッセージヘッダフィールドを使用するための規則は、また、SIPにも適用されます。ザ・
Global-Failure | "600" ; Busy Everywhere
| "603" ; Decline
| "604" ; Does not exist anywhere
| "606" ; Not Acceptable
Figure 9: Global failure status codes
図9：グローバル障害のステータスコード
rules in [H4.2] regarding ordering of header fields apply to SIP, with the exception of Via fields, see below, whose order matters. Additionally, header fields which are hop-by-hop MUST appear before any header fields which are end-to-end. Proxies SHOULD NOT reorder header fields. Proxies add Via header fields and MAY add other hop-by-hop header fields. They can modify certain header fields, such as Max-Forwards (Section 6.23) and "fix up" the Via header fields with "received" parameters as described in Section 6.40.1. Proxies MUST NOT alter any fields that are authenticated (see Section 13.2).
ヘッダフィールドの順序に関して[H4.2]のルールは、オーダー事項のViaフィールド、下記を参照の例外を除いて、SIPに適用されます。また、ホップバイホップされるヘッダフィールドは、エンドツーエンドである任意のヘッダフィールドの前に現れなければなりません。プロキシはヘッダフィールドの順序を変更すべきではありません。プロキシは、Viaヘッダフィールドを追加し、他のホップバイホップヘッダフィールドを追加するかもしれません。それらは、最大転送し（セクション6.23）とのような特定のヘッダフィールドを変更することができ、セクション6.40.1に記載されているようにとのViaヘッダフィールドは、パラメータを「受信」「フィックスアップ」。プロキシは（13.2節を参照）が認証されるすべてのフィールドを変更してはなりません。
The header fields required, optional and not applicable for each method are listed in Table 4 and Table 5. The table uses "o" to indicate optional, "m" mandatory and "-" for not applicable. A "*" indicates that the header fields are needed only if message body is not empty. See sections 6.15, 6.16 and 8 for details.
オプションで、各方法には適用できない必須のヘッダフィールドは、「M」は必須と、テーブルがオプションを示すために、「O」を使用し、表4及び表5に記載されている「 - 」は適用できないため。 「*」は、ヘッダフィールドは、メッセージ本体が空でない場合にのみ必要とされていることを示しています。セクション詳細については、6.15、6.16および8を参照してください。
The "where" column describes the request and response types with which the header field can be used. "R" refers to header fields that can be used in requests (that is, request and general header fields). "r" designates a response or general-header field as applicable to all responses, while a list of numeric values indicates the status codes with which the header field can be used. "g" and "e" designate general (Section 6.1) and entity header (Section 6.2) fields, respectively. If a header field is marked "c", it is copied from the request to the response.
「ここ」の列は、ヘッダーフィールドが使用可能な要求と応答のタイプを記述する。 「R」は、要求（つまり、要求及び一般的なヘッダフィールド）に使用することができるフィールドをヘッダを参照します。数値のリストは、ヘッダフィールドが使用可能な状態コードを示しながら、「R」は、すべての応答に対する応答として適用または一般的なヘッダフィールドを指定します。 「G」および「E」を指定一般的な（セクション6.1）と、それぞれのエンティティヘッダ（セクション6.2）フィールド。ヘッダフィールドは「C」とマークされている場合は、応答への要求からコピーされます。
The "enc." column describes whether this message header field MAY be encrypted end-to-end. A "n" designates fields that MUST NOT be encrypted, while "c" designates fields that SHOULD be encrypted if encryption is used.
"ENC。"列は、このメッセージのヘッダフィールドは、エンドツーエンドの暗号化されてもよいかどうかを記述する。 「N」は「c」は、暗号化が使用されている場合、暗号化されるフィールドを指定しながら、暗号化されてはならないフィールドを指定します。
The "e-e" column has a value of "e" for end-to-end and a value of "h" for hop-by-hop header fields.
「E-E」欄は、エンドツーエンドのために「E」の値とホップバイホップヘッダフィールドの「H」の値を有します。
where enc. e-e ACK BYE CAN INV OPT REG
__________________________________________________________
Accept R e - - - o o o
Accept 415 e - - - o o o
Accept-Encoding R e - - - o o o
Accept-Encoding 415 e - - - o o o
Accept-Language R e - o o o o o
Accept-Language 415 e - o o o o o
Allow 200 e - - - - m -
Allow 405 e o o o o o o
Authorization R e o o o o o o
Call-ID gc n e m m m m m m
Contact R e o - - o o o
Contact 1xx e - - - o o -
Contact 2xx e - - - o o o
Contact 3xx e - o - o o o
Contact 485 e - o - o o o
Content-Encoding e e o - - o o o
Content-Length e e o - - o o o
Content-Type e e * - - * * *
CSeq gc n e m m m m m m
Date g e o o o o o o
Encryption g n e o o o o o o
Expires g e - - - o - o
From gc n e m m m m m m
Hide R n h o o o o o o
Max-Forwards R n e o o o o o o
Organization g c h - - - o o o
Table 4: Summary of header fields, A--O
表4：ヘッダーフィールドの概要、A - O
Other header fields can be added as required; a server MUST ignore header fields not defined in this specification that it does not understand. A proxy MUST NOT remove or modify header fields not defined in this specification that it does not understand. A compact form of these header fields is also defined in Section 9 for use over UDP when the request has to fit into a single packet and size is an issue.
他のヘッダフィールドは、必要に応じて添加することができます。サーバはそれが理解できないこの仕様で定義されていないヘッダフィールドを無視しなければなりません。プロキシは、それが理解できないことを、この仕様で定義されていないヘッダフィールドを削除したり、変更してはいけません。要求が単一のパケットに収まる必要があり、サイズが問題である場合、これらのヘッダフィールドのコンパクト形はまた、UDP上で使用するためのセクション9で定義されています。
Table 6 in Appendix A lists those header fields that different client and server types MUST be able to parse.
付録Aの表6は、異なるクライアントおよびサーバタイプが解析できなければならないこれらのヘッダーフィールドを示しています。
General header fields apply to both request and response messages. The "general-header" field names can be extended reliably only in combination with a change in the protocol version. However, new or
一般ヘッダフィールドは、要求と応答メッセージの両方に適用されます。 「一般的なヘッダ」フィールド名はプロトコルバージョンにおける変化との組み合わせでのみ確実に拡張することができます。ただし、新規または
where enc. e-e ACK BYE CAN INV OPT REG
___________________________________________________________________
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R e o o o o o o
Retry-After R c e - - - - - o
Retry-After 404,480,486 c e o o o o o o
503 c e o o o o o o
600,603 c e o o o o o o
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h o o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To gc(1) n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o
Via gc(2) n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o
Table 5: Summary of header fields, P--Z; (1): copied with possible addition of tag; (2): UAS removes first Via header field
表5：ヘッダフィールドの概要、P - Z。 （1）：タグの可能加えてコピー。 （2）：UASは、ヘッダフィールドを介して第一削除します
experimental header fields MAY be given the semantics of general header fields if all parties in the communication recognize them to be "general-header" fields. Unrecognized header fields are treated as "entity-header" fields.
通信のすべての当事者が「一般ヘッダ」フィールドであることをそれらを認識した場合、実験のヘッダーフィールドは、一般的なヘッダフィールドの意味論を与えてもよいです。認識されていないヘッダフィールドは、「エンティティヘッダ」フィールドとして扱われます。
The "entity-header" fields define meta-information about the message-body or, if no body is present, about the resource identified by the request. The term "entity header" is an HTTP 1.1 term where the response body can contain a transformed version of the message body. The original message body is referred to as the "entity". We retain the same terminology for header fields but usually refer to the "message body" rather then the entity as the two are the same in SIP.
全く体が存在しない場合、「エンティティヘッダ」フィールドは、要求によって識別されたリソースについて、メッセージボディに関するメタ情報を定義したり。用語「エンティティヘッダは、」応答ボディは、メッセージ本体の形質転換されたバージョンを含むことができるHTTP 1.1用語です。元のメッセージ体を「エンティティ」と呼ばれます。我々は、ヘッダフィールドの同じ用語を保持するが、2つのSIPに同じであるように、通常、「メッセージ本文」というしエンティティを指します。
The "request-header" fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters of a programming language method invocation.
「リクエストヘッダ」フィールドは、クライアントが要求に関する追加情報を渡すことができ、クライアント自体については、サーバーに。これらのフィールドは、プログラミング言語のメソッド呼び出しのパラメータと同等の意味を持つ、リクエスト修飾子として動作します。
The "request-header" field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of "request-header" fields if all parties in the communication recognize them to be request-header fields. Unrecognized header fields are treated as "entity-header" fields.
「リクエストヘッダ」フィールド名はプロトコルバージョンにおける変化との組み合わせでのみ確実に拡張することができます。通信のすべての当事者がリクエストヘッダフィールドであることをそれらを認識場合は、新しいまたは実験ヘッダフィールドは、「リクエストヘッダ」フィールドの意味論を与えてもよいです。認識されていないヘッダフィールドは、「エンティティヘッダ」フィールドとして扱われます。
The "response-header" fields allow the server to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
「レスポンス・ヘッダー」フィールドは、サーバーがステータスラインに配置することはできません応答に関する追加情報を渡すことができます。これらのヘッダーフィールドは、サーバに関するとRequest-URIによって識別されたリソースへのさらなるアクセスについての情報を与えます。
Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of "response-header" fields if all parties in the communication recognize them to be "response-header" fields. Unrecognized header fields are treated as "entity-header" fields.
レスポンスヘッダフィールド名はプロトコルバージョンにおける変化との組み合わせでのみ確実に拡張することができます。通信のすべての当事者が「レスポンスヘッダ」フィールドであることをそれらを認識場合は、新しいまたは実験ヘッダフィールドは、「レスポンス・ヘッダー」フィールドの意味論を与えてもよいです。認識されていないヘッダフィールドは、「エンティティヘッダ」フィールドとして扱われます。
End-to-end headers MUST be transmitted unmodified across all proxies, while hop-by-hop headers MAY be modified or added by proxies.
ホップバイホップヘッダは変更またはプロキシによって追加することができるが、エンドツーエンドのヘッダは、すべてのプロキシを横断修飾されていない送信されなければなりません。
Header fields ("general-header", "request-header", "response-header", and "entity-header") follow the same generic header format as that given in Section 3.1 of RFC 822 [24]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of leading white space (LWS), though a single space (SP) is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). Applications MUST follow HTTP "common form" when generating these constructs, since there might exist some implementations that fail to accept anything beyond the common forms.
ヘッダフィールド（「一般的なヘッダ」、「リクエストヘッダ」、「レスポンスヘッダ」、および「エンティティヘッダ」）RFC 822 [24]のセクション3.1で与えられたものと同じ一般的なヘッダフォーマットに従います。フィールド値：各ヘッダフィールドは、コロン（「」）が続く名前で構成されています。フィールド名は大文字と小文字を区別しません。単一空間（SP）が好ましいが、フィールド値は、先頭の空白（LWS）の任意の量によって先行されるかもしれません。ヘッダフィールドは、少なくとも1つのSPまたは水平タブ（HT）と各追加のラインを先行することによって、複数の行にわたって拡張することができます。これらの構成要素を生成するときの一般的なフォームを超えた何かを受け入れるように失敗するいくつかの実装が存在する可能性があるため、アプリケーションは、HTTP、「一般的な形式を」従わなければなりません。
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = < the OCTETs making up the field-value
and consisting of either *TEXT-UTF8
or combinations of token,
separators, and quoted-string>
The relative order of header fields with different field names is not significant. Multiple header fields 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 (i.e., #(values)). It MUST be possible to combine the multiple header fields 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 order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
異なるフィールド名を持つヘッダフィールドの相対的な順序は重要ではありません。同じフィールド名を持つ複数のヘッダフィールドは、ヘッダフィールドの全体のフィールド値をカンマ区切りリスト（すなわち、＃（値））として定義されている場合に限り、メッセージ内に存在してもよいです。カンマで区切られ、最初に後続の各フィールド値を追加することによって、メッセージのセマンティクスを変更することなく、「フィールド値のフィールド名」ペア1つに複数のヘッダフィールドを組み合わせることが可能でなければなりません。同じフィールド名を持つヘッダフィールドが受信される順序は、結合フィールド値の解釈することが重要であり、メッセージが転送されるとき、したがって、プロキシは、これらのフィールドの値の順序を変更しないでください。
Field names are not case-sensitive, although their values may be.
それらの値があってもよいが、フィールド名は、大文字と小文字を区別しません。
The Accept header follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header is present, the server SHOULD assume a default value of application/sdp.
Acceptヘッダーは[H14.1]で定義された構文に従います。セマンティクスには受け入れヘッダが存在しない場合、サーバは、アプリケーション/ SDPのデフォルト値をとるべきであることを除いて、また同じです。
This request-header field is used only with the INVITE, OPTIONS and REGISTER request methods to indicate what media types are acceptable in the response.
このリクエストヘッダフィールドは、メディアタイプが応答で許容されるものを示すために、OPTIONSを招待REGISTER要求方法で使用されています。
Example:
例：
Accept: application/sdp;level=1, application/x-private, text/html
受け入れ：アプリケーション/ SDPと、レベル= 1、アプリケーション/ X-プライベート、テキスト/ HTML
The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings [H3.4.1] that are acceptable in the response. See [H14.3]. The syntax of this header is defined in [H14.3]. The semantics in SIP are identical to those defined in [H14.3].
Accept-Encodingリクエスト・ヘッダー・フィールドは、そのまま使用することが同様であるが、応答に許容される内容コーディング[H3.4.1]を制限します。 [H14.3]を参照してください。このヘッダの構文は[H14.3]で定義されています。 SIP内のセマンティクスは[H14.3]で定義されたものと同一です。
The Accept-Language header follows the syntax defined in [H14.4]. The rules for ordering the languages based on the q parameter apply to SIP as well. When used in SIP, the Accept-Language request-header field can be used to allow the client to indicate to the server in which language it would prefer to receive reason phrases, session descriptions or status responses carried as message bodies. A proxy MAY use this field to help select the destination for the call, for example, a human operator conversant in a language spoken by the caller.
Accept-Languageヘッダは[H14.4]で定義された構文に従います。 qパラメータに基づいて言語を注文するためのルールも同様にSIPに適用されます。 SIPで使用する場合、Accept-Languageリクエストヘッダフィールドは、クライアントがメッセージ本文として運ば理由フレーズ、セッション記述やステータス応答を受け取ることを好むだろうどの言語にサーバーに指示できるようにするために使用することができます。プロキシは、発信者によって話された言語では、例えば、コールの送信先を選択できるように精通人間のオペレータがこのフィールドを使用するかもしれません。
Example:
例：
Accept-Language: da, en-gb;q=0.8, en;q=0.7
受け入れ-言語：DA、EN-GB; Q = 0.8、EN; Q = 0.7
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response and SHOULD be present in an OPTIONS response.
許可エンティティヘッダフィールドは、Request-URIによって識別されたリソースによってサポートされるメソッドのセットを一覧表示します。このフィールドの目的は、リソースに関連する有効な方法の受信者に通知するために厳密です。許可ヘッダフィールドは405（方法不可）応答中に存在しなければならないとOPTIONS応答で存在すべきです。
Allow = "Allow" ":" 1#Method
= "は "許可" を許可：" 1つの＃メソッド
A user agent that wishes to authenticate itself with a server -- usually, but not necessarily, after receiving a 401 response -- MAY do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
401応答を受信した後、必ずしも通常、しかし - - サーバでそれ自体を認証することを望むユーザエージェントは、要求と認可要求ヘッダフィールドを含めることでそれを行うことができます。 Authorizationフィールド値は、要求されたリソースのレルムのユーザエージェントの認証情報を含む資格情報で構成されています。
Section 13.2 overviews the use of the Authorization header, and section 15 describes the syntax and semantics when used with PGP based authentication.
セクション13.2は、Authorizationヘッダの使用を概観し、PGPベースの認証で使用するとき部15は、シンタックスとセマンティクスを記述しています。
The Call-ID general-header field uniquely identifies a particular invitation or all registrations of a particular client. Note that a single multimedia conference can give rise to several calls with different Call-IDs, e.g., if a user invites a single individual several times to the same (long-running) conference.
コールID一般的なヘッダフィールドは、一意に特定の招待または特定のクライアントのすべての登録を識別する。ユーザーが同じ（長時間実行）会議に単一の個人、数回を誘う場合は、例えば、単一のマルチメディア会議が異なるコールIDを持ついくつかの呼び出しに生じさせることができることに注意してください。
For an INVITE request, a callee user agent server SHOULD NOT alert the user if the user has responded previously to the Call-ID in the INVITE request. If the user is already a member of the conference and the conference parameters contained in the session description have not changed, a callee user agent server MAY silently accept the call, regardless of the Call-ID. An invitation for an existing Call-ID or session can change the parameters of the conference. A client application MAY decide to simply indicate to the user that the conference parameters have been changed and accept the invitation automatically or it MAY require user confirmation.
ユーザーがINVITEリクエストでのCall-IDに以前に応答した場合、INVITEリクエストの場合は、呼び出し先のユーザエージェントサーバは、ユーザに警告すべきではありません。ユーザが既に会議のメンバーであり、セッション記述に含まれる会議パラメータが変更されていない場合は、呼び出し先のユーザエージェントサーバは静かにかかわらず、コールIDのコールを受け入れることができます。既存のCall-IDやセッションの招待状は、会議のパラメータを変更することができます。クライアントアプリケーションは、単に会議パラメータが変更され、自動的に招待を受け入れるか、それがユーザの確認を必要とするかもしれされていることをユーザに示すことを決定することができます。
A user may be invited to the same conference or call using several different Call-IDs. If desired, the client MAY use identifiers within the session description to detect this duplication. For example, SDP contains a session id and version number in the origin (o) field.
ユーザーは、いくつかの異なるコールIDを使用して、同じ会議またはコールに招待することができます。必要であれば、クライアントはこの重複を検出するために、セッション記述の中に識別子を使用することができます。例えば、SDPは、原点（O）フィールドにセッションIDとバージョン番号を含みます。
The REGISTER and OPTIONS methods use the Call-ID value to unambiguously match requests and responses. All REGISTER requests issued by a single client SHOULD use the same Call-ID, at least within the same boot cycle.
REGISTERおよびOPTIONSメソッドは明確に要求と応答に一致するようにコール-ID値を使用します。単一のクライアントによって発行されたすべてのREGISTER要求は、少なくとも同じブート・サイクル内で、同じCall-IDを使用する必要があります。
Since the Call-ID is generated by and for SIP, there is no
reason to deal with the complexity of URL-encoding and
case-ignoring string comparison.
Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host local-id = 1*uric
コールID =（ "コール-ID" | "I"） "：" ローカル-ID = 1 *尿をホスト "@" ローカル-ID
"host" SHOULD be either a fully qualified domain name or a globally routable IP address. If this is the case, the "local-id" SHOULD be an identifier consisting of URI characters that is unique within "host". Use of cryptographically random identifiers [27] is RECOMMENDED. If, however, host is not an FQDN or globally routable IP address (such as a net 10 address), the local-id MUST be globally unique, as opposed to unique within host. These rules guarantee overall global uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused for a different call. Call-IDs are case-sensitive.
「ホスト」完全修飾ドメイン名またはグローバルにルーティング可能なIPアドレスのいずれかでなければなりません。この場合、「ローカルID」は、「ホスト」内で一意であるURI文字からなる識別子であるべきです。暗号的にランダムな識別子[27]の使用をお勧めします。しかし、ホストはFQDNまたは（例えばネット10のアドレスなど）、グローバルにルーティング可能なIPアドレスでない場合、ホスト内で一意とは対照的に、ローカルIDは、グローバルに一意でなければなりません。これらのルールは、コールIDの全体的なグローバル一意性を保証します。コールIDの値が異なるコールのために再利用してはなりません。コールIDは大文字と小文字が区別されます。
Using cryptographically random identifiers provides some
protection against session hijacking. Call-ID, To and From
are needed to identify a call leg. The distinction between
call and call leg matters in calls with third-party
control.
For systems which have tight bandwidth constraints, many of the mandatory SIP headers have a compact form, as discussed in Section 9. These are alternate names for the headers which occupy less space in the message. In the case of Call-ID, the compact form is i.
第9節で説明したようにタイトな帯域幅の制約を持つシステムでは、義務的なSIPヘッダの多くは、コンパクトなフォームを持って、これらは、メッセージに少ないスペースを占有し、ヘッダーの代替名です。コール-IDの場合には、コンパクトなフォームは私です。
For example, both of the following are valid:
たとえば、次の両方が有効です。
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
コールID：f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
or
または
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
I：f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
The Contact general-header field can appear in INVITE, ACK, and REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In general, it provides a URL where the user can be reached for further communications.
連絡先一般ヘッダフィールドは、で表示されACK、INVITE、および要求を登録し、1XX、2XX、3XX、および485で応答することができます。一般に、ユーザがさらなる通信のために到達することができるURLを提供します。
INVITE and ACK requests: INVITE and ACK requests MAY contain Contact headers indicating from which location the request is originating.
INVITEとACK要求：INVITEとACK要求は、要求が発信された場所から指示する連絡先ヘッダを含むかもしれません。
This allows the callee to send future requests, such as
BYE, directly to the caller instead of through a series of
proxies. The Via header is not sufficient since the
desired address may be that of a proxy.
INVITE 2xx responses: A user agent server sending a definitive, positive response (2xx) MAY insert a Contact response header field indicating the SIP address under which it is reachable most directly for future SIP requests, such as ACK, within the same Call-ID. The Contact header field contains the address of the server itself or that of a proxy, e.g., if the host is behind a firewall. The value of this Contact header is copied into the Request-URI of subsequent requests for this call if the response did not also contain a Record-Route header. If the response also contains a Record-Route header field, the address in the Contact header field is added as the last item in the Route header field. See Section 6.29 for details.
2xx応答をINVITE：決定的な、肯定応答（2xxの）を送信するユーザエージェントサーバは、同じCall-IDの中に、そのようなACKとして将来SIPリクエストのために最も直接的に到達可能で、その下SIPアドレスを示す問い合わせレスポンスヘッダフィールドを挿入することができます。ホストがファイアウォールの背後にある場合はContactヘッダーフィールドは、例えば、サーバ自体またはプロキシのそれのアドレスが含まれています。応答はまた、Record-Routeヘッダが含まれていなかった場合には、このコンタクトヘッダの値は、この呼び出しのために、後続の要求の要求URIにコピーされます。応答はまた、Record-Routeヘッダーフィールドが含まれている場合は、Contactヘッダーフィールドのアドレスは、Routeヘッダーフィールドの最後の項目として追加されます。詳細については、セクション6.29を参照してください。
The Contact value SHOULD NOT be cached across calls, as it
may not represent the most desirable location for a
particular destination address.
INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY insert a Contact response header. It has the same semantics in a 1xx response as a 2xx INVITE response. Note that CANCEL requests MUST NOT be sent to that address, but rather follow the same path as the original request.
1XX応答をINVITE：UASは、暫定的な応答（1XX）を送信する問い合わせ応答ヘッダーを挿入することができます。それはINVITE応答の2xxなどの1xx応答で同じ意味を持っています。 CANCELリクエストを注記は、そのアドレスに送信されたのではなく、元の要求と同じ道をたどるてはなりません。
REGISTER requests: REGISTER requests MAY contain a Contact header field indicating at which locations the user is reachable. The REGISTER request defines a wildcard Contact field, "*", which MUST only be used with Expires: 0 to remove all registrations for a particular user. An optional "expires" parameter indicates the desired expiration time of the registration. If a Contact entry does not have an "expires" parameter, the Expires header field is used as the default value. If neither of these mechanisms is used, SIP URIs are assumed to expire after one hour. Other URI schemes have no expiration times.
リクエストを登録：REGISTER要求は、ユーザが到達可能な位置で示すContactヘッダーフィールドを含むかもしれません。 0を特定のユーザーのすべての登録を削除するには：REGISTER要求にのみに使用しなければならないワイルドカードContactフィールド、「*」は、有効期限を定義します。オプションのパラメータは、登録の希望有効期限を示す「期限が切れます」。連絡先のエントリが「expires」パラメータがない場合は、有効期限ヘッダーフィールドは、デフォルト値として使用されます。これらのメカニズムのどちらを使用する場合は、SIP URIを、1時間後に期限切れと想定されています。他のURIスキームには有効期限がありません。
REGISTER 2xx responses: A REGISTER response MAY return all locations at which the user is currently reachable. An optional "expires" parameter indicates the expiration time of the registration. If a Contact entry does not have an "expires" parameter, the value of the Expires header field indicates the expiration time. If neither mechanism is used, the expiration time specified in the request, explicitly or by default, is used.
2xx応答を登録します。REGISTER応答は、ユーザーが現在到達可能で、すべての場所を返してもよいです。オプションのパラメータは、登録の有効期限を示す「期限が切れます」。連絡先のエントリは、「期限が切れる」のパラメータを持っていない場合は、の値はヘッダフィールドは有効期限を示し有効期限。どちらのメカニズムが使用されている場合は、要求に指定された有効期限は、明示的またはデフォルトで、使用されています。
3xx and 485 responses: The Contact response-header field can be used with a 3xx or 485 (Ambiguous) response codes to indicate one or more alternate addresses to try. It can appear in responses to BYE, INVITE and OPTIONS methods. The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 300 (Multiple Choices), 301 (Moved Permanently), 302 (Moved Temporarily) or 485 (Ambiguous) response SHOULD contain a Contact field containing URIs of new addresses to be tried. A
3XXと485応答：接触レスポンス・ヘッダー・フィールドはしようとする1つ以上の代替アドレスを示すために、3XXまたは485（曖昧な）応答コードと共に使用することができます。それはBYE、INVITEとOPTIONSメソッドへの応答に現れることができます。 ContactヘッダーフィールドはURIがしようとする新しい場所またはユーザー名を与える、または単に追加のトランスポートパラメータを指定することも含まれています。 300（複数の選択肢）、301（恒久的に移動）、302（一時的に移動）または485（曖昧な）応答が試されるべき新しいアドレスのURIを含む連絡先フィールドを含むべきです。 A
301 or 302 response may also give the same location and username
that was being tried 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. The
client copies the "user", "password", "host", "port" and "user-
param" elements of the Contact URI into the Request-URI of the
redirected request and directs the request to the address
specified by the "maddr" and "port" parameters, using the
transport protocol given in the "transport" parameter. If
"maddr" is a multicast address, the value of "ttl" is used as
the time-to-live value.
Note that the Contact header field MAY also refer to a different entity than the one originally called. For example, a SIP call connected to GSTN gateway may need to deliver a special information announcement such as "The number you have dialed has been changed."
Contactヘッダーフィールドも元々呼ばれるものとは別のエンティティを参照する場合があります。例えば、GSTNゲートウェイに接続されたSIPコールは、次のような特別な情報の発表を提供する必要があるかもしれません「あなたがダイヤルしている番号が変更されました。」
A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URLs. For example, it could contain URL's for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368, [28]) URL.
問い合わせレスポンスヘッダフィールドは、被呼者がSIPのURLに限定されるものではなく、到達することができる場所を示す任意の適切なURIを含むことができます。 （RFC 2368、[28]）URL：たとえば、URLの電話、ファックス、またはIRCのために（それらが定義されている場合）、またはmailtoのを含めることができます。
The following parameters are defined. Additional parameters may be defined in other specifications.
以下のパラメータが定義されています。追加のパラメータは、他の仕様で定義されてもよいです。
q: The "qvalue" indicates the relative preference among the locations given. "qvalue" values are decimal numbers from 0 to 1, with higher values indicating higher preference.
Q：「のqvalue」は、与えられた位置の間で相対的優先度を示しています。 「のqvalue」値は、より高い優先度を示す高い値で、0から1の小数です。
action: The "action" parameter is used only when registering with the REGISTER request. It indicates whether the client wishes that the server proxy or redirect future requests intended for the client. If this parameter is not specified the action taken depends on server configuration. In its response, the registrar SHOULD indicate the mode used. This parameter is ignored for other requests.
アクション：「アクション」パラメータがREGISTERリクエストを登録する場合にのみ使用されます。これは、クライアントがサーバのプロキシまたはクライアントを対象とし、将来の要求をリダイレクトすることを希望するかどうかを示します。このパラメータが指定されていない場合取られるアクションは、サーバの設定に依存します。その応答では、レジストラが使用するモードを示すべきです。このパラメータは、他の要求は無視されます。
expires: The "expires" parameter indicates how long the URI is valid. The parameter is either a number indicating seconds or a quoted string containing a SIP-date. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1.
期限が切れる：パラメータは、URIが有効である期間を示し、「期限が切れます」。パラメータは、秒を示す番号またはSIP-日付を含む引用符で囲まれた文字列のいずれかです。このパラメータが提供されていない場合、有効期限ヘッダーフィールドの値は、URIが有効である期間を決定します。実装は** 32-1 2と同等に2 ** 32-1（4294967295秒または136年）よりも大きな値を扱うかもしれ。
Contact = ( "Contact" | "m" ) ":" ("*" | (1# (( name-addr | addr-spec ) [ *( ";" contact-params ) ] [ comment ] )))
連絡先=（ "連絡先" | "M"） "："（ "*" |（1＃（（名-addrに| ADDR-仕様）[*（ ";" コンタクトのparams）] [コメント]）））
name-addr = [ display-name ] "<" addr-spec ">" addr-spec = SIP-URL | URI display-name = *token | quoted-string
名前-addrに= [表示名] "<" のaddrスペック ">" のaddrスペック= SIP-URL | URIの表示名= *トークン|引用符で囲まれた文字列
contact-params = "q" "=" qvalue | "action" "=" "proxy" | "redirect" | "expires" "=" delta-seconds | <"> SIP-date <"> | extension-attribute
連絡-のparams = "Q" "=" のqvalue | 「アクション」「=」「プロキシ」| |「リダイレクト」 「有効期限が切れる」「=」デルタ秒| < "> SIP-日<"> |拡張属性
extension-attribute = extension-name [ "=" extension-value ]
拡張属性=拡張子名[「=」拡張値]
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.
The current syntax corresponds to that for the To and From
header, which also allows the use of display names.
Example:
例：
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> ;q=0.7; expires=3600, "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
連絡先： "氏ワトソン" <一口：watson@worcester.bell-telephone.com>; Q = 0.7; Q = 0.1; = 3600、 "氏ワトソン" <watson@bell-telephone.comのmailto>満了します
Content-Encoding = ( "Content-Encoding" | "e" ) ":"
1#content-coding
The Content-Encoding entity-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-Typeヘッダフィールドによって参照されるメディアタイプを得るために適用されなければならないものこうしてエンティティボディに適用されてきたものを示しています。コンテンツのエンコーディングは、主に体がその根底にあるメディアタイプのアイデンティティを失わずに圧縮することができるようにするために使用されます。
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.
複数のエンコーディングがエンティティに適用されている場合は、コンテンツのコーディングは、それらが適用された順にリストされなければなりません。
All content-coding values are case-insensitive. The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. See [3.5] for a definition of the syntax for content-coding.
すべてのコンテンツコーディング値は、大文字と小文字を区別しません。 IANA（Internet Assigned Numbers Authority）は、コンテンツコード値トークンのレジストリとして作用します。コンテンツコードの構文の定義については、[3.5]を参照してください。
Clients MAY apply content encodings to the body in requests. If the server is not capable of decoding the body, or does not recognize any of the content-coding values, it MUST send a 415 "Unsupported Media Type" response, listing acceptable encodings in the Accept-Encoding header. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header in the request.
クライアントがリクエストで、本体へのコンテンツのエンコーディングを適用することができます。サーバは、本体をデコードすることができない、あるいはコンテンツコード値のいずれかを認識しない場合、それは受け入れ-Encodingヘッダーに許容されるエンコーディングをリスト、415「サポートされていないメディアタイプ」応答を送信しなければなりません。サーバは、応答のボディに、コンテンツのエンコーディングを適用することができます。サーバは、要求内のAccept-Encodingヘッダに記載されているエンコーディングを使用しなければなりません。
The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.
Content-Lengthエンティティヘッダフィールドは、受信者に送信されたオクテットの10進数で、メッセージボディのサイズを示します。
Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT
コンテンツの長さ=（ "のContent-Length" | "L"） "：" 1 * DIGIT
An example is
例があります
Content-Length: 3495
コンテンツの長さ：3495
Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. 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 MUST be set to zero. If a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet. If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response. If there is additional data in the UDP packet after the last byte of the body has been read, the server MUST treat the remaining data as a separate message. This allows several messages to be placed in a single UDP packet.
アプリケーションは関係なく、エンティティのメディアタイプの、転送されるメッセージボディのサイズを示すために、このフィールドを使用すべきです。 0以上の任意のContent-Lengthは有効な値です。全く体がメッセージに存在しない場合には、Content-Lengthヘッダフィールドはゼロに設定しなければなりません。サーバーがコンテンツ長なしUDP要求を受信した場合、その要求は、パケットの残りの部分を包含することを仮定しなければなりません。サーバーがコンテンツ長とUDP要求を受信し、その値は、要求で送信された身体のサイズよりも大きい場合、クライアントは400クラスの応答を生成する必要があります。体の最後のバイトが読み込まれた後にUDPパケットに追加のデータがある場合は、サーバが別々のメッセージとして、残りのデータを扱わなければなりません。これは、いくつかのメッセージが単一のUDPパケットに配置することができます。
If a response does not contain a Content-Length, the client assumes that it encompasses the remainder of the UDP packet or the data until the TCP connection is closed, as applicable. Section 8 describes how to determine the length of the message body.
応答がコンテンツの長さが含まれていない場合、クライアントは、TCP接続がクローズされるまで、それが該当する場合、UDPパケットの残りの部分やデータを包含することを前提としています。第8章は、メッセージ本体の長さを決定する方法について説明します。
The Content-Type entity-header field indicates the media type of the message-body sent to the recipient. The "media-type" element is defined in [H3.7].
Content-Typeエンティティヘッダフィールドは、受信者に送信されるメッセージボディのメディアタイプを示しています。 「メディアタイプ」エレメントは[H3.7]で定義されています。
Content-Type = ( "Content-Type" | "c" ) ":" media-type
Content-Typeの=（ "Content-Typeの" | "C"） "：" メディアタイプ
Examples of this header field are
このヘッダフィールドの例であります
Content-Type: application/sdp Content-Type: text/html; charset=ISO-8859-4
コンテンツタイプ：アプリケーション/ SDPのContent-Type：text / htmlの。文字セット= ISO-8859-4
Clients MUST add the CSeq (command sequence) general-header field to every request. A CSeq header field in a request contains the request method and a single decimal sequence number chosen by the requesting client, unique within a single value of Call-ID. The sequence number MUST be expressible as a 32-bit unsigned integer. The initial value of the sequence number is arbitrary, but MUST be less than 2**31. Consecutive requests that differ in request method, headers or body, but have the same Call-ID MUST contain strictly monotonically increasing and contiguous sequence numbers; sequence numbers do not wrap around. Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a "re-invitation") acquires a new, higher sequence number. A server MUST echo the CSeq value from the request in its response. If the Method value is missing in the received CSeq header field, the server fills it in appropriately.
クライアントは、すべての要求へのCSeq（コマンドシーケンス）一般的なヘッダフィールドを追加しなければなりません。要求におけるCSeqヘッダーフィールドは、要求メソッドとコールIDの単一の値内で一意要求するクライアントによって選択された単一進シーケンス番号を含んでいます。シーケンス番号は32ビットの符号なし整数として表現可能でなければなりません。シーケンス番号の初期値は任意であるが、** 31 2未満でなければなりません。リクエストメソッド、ヘッダや本文に異なるが、同じCall-IDは厳密に単調に増加し、連続したシーケンス番号が含まれなければならない持っている連続した要求。シーケンス番号がラップアラウンドしません。同じ要求の再送信は、同じシーケンス番号を運ぶが、異なるメッセージ本文または異なるヘッダフィールド（「再招待」）を用いてINVITEは、新しい、より高いシーケンス番号を取得します。サーバは、その応答でリクエストからのCSeq値をエコーしなければなりません。メソッドの値は、受信CSeqヘッダーフィールドにおいて欠落している場合、サーバは、適切にそれを充填します。
The ACK and CANCEL requests MUST contain the same CSeq value as the INVITE request that it refers to, while a BYE request cancelling an invitation MUST have a higher sequence number. A BYE request with a CSeq that is not higher should cause a 400 response to be generated.
招待をキャンセルBYE要求がより高いシーケンス番号が必要ながらACKとCANCEL要求は、それが指すINVITE要求と同様のCSeq値を含まなければなりません。高くないのCSeqとBYE要求は400応答を発生させる必要があります。
A user agent server MUST remember the highest sequence number for any INVITE request with the same Call-ID value. The server MUST respond to, and then discard, any INVITE request with a lower sequence number.
ユーザエージェントサーバは、任意のための最高のシーケンス番号が同じCall-ID値でINVITEリクエストを覚えておく必要があります。サーバーは、任意の小さいシーケンス番号を持つINVITEリクエストを、に反応し、その後、捨てなければなりません。
All requests spawned in a parallel search have the same CSeq value as the request triggering the parallel search.
並列検索で生成されたすべての要求は、並列検索をトリガーする要求と同じのCSeq値を持っています。
CSeq = "CSeq" ":" 1*DIGIT Method
CSeq = "のCSeq" "：" 1つの* DIGIT方法
Strictly speaking, CSeq header fields are needed for any SIP request that can be cancelled by a BYE or CANCEL request or where a client can issue several requests for the same Call-ID in close succession. Without a sequence number, the response to an INVITE could be mistaken for the response to the cancellation (BYE or CANCEL). Also, if the network duplicates packets or if an ACK is delayed until the server has sent an additional response, the client could interpret an old response as the response to a re-invitation issued shortly thereafter. Using CSeq also makes it easy for the server to distinguish different versions of an invitation, without comparing the message body.
厳密に言えば、CSeqヘッダーフィールドはBYEによってキャンセルまたは要求や場所クライアントが近い連続して同じCall-IDのためのいくつかの要求を発行することができますをキャンセルすることができます任意のSIPリクエストのために必要とされます。シーケンス番号なし、INVITEに対する応答は（BYEまたはCANCEL）取消に対する応答を誤解することができます。また、ネットワークがパケットを複製した場合や、サーバーが追加のレスポンスを送信したまでACKが遅延した場合、クライアントは、その後まもなく発行される再招待への応答として古い応答を解釈することができます。サーバがメッセージボディを比較することなく、招待状の異なるバージョンを区別するためのCSeqを使用すると、それが容易になります。
The Method value allows the client to distinguish the response to an INVITE request from that of a CANCEL response. CANCEL requests can be generated by proxies; if they were to increase the sequence number, it might conflict with a later request issued by the user agent for the same call.
メソッドの値は、クライアントがCANCEL応答とからINVITE要求への応答を区別することを可能にします。プロキシによって生成することができるの要求をキャンセル。彼らは、シーケンス番号を増加した場合、それは同じコールのためのユーザエージェントによって発行された後の要求と競合する可能性があります。
With a length of 32 bits, a server 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 to use a time-based initial sequence number, if the client desires. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial sequence number.
32ビットの長さでは、サーバーは、単一コール内で、ラップアラウンドする必要が前におよそ136年の二つの要求を生成することができます。同じ呼び出し内の後続の要求がラップアラウンドしないように、シーケンス番号の初期値が選択されています。ゼロ以外の初期値は、クライアントが希望する場合には、時間ベースの初期シーケンス番号を使用することができます。クライアントは、例えば、初期シーケンス番号として32ビットの第2のクロックの31個の最上位ビットを選ぶことができます。
Forked requests MUST have the same CSeq as there would be ambiguity otherwise between these forked requests and later BYE issued by the client user agent.
これらのフォークを要求し、クライアントのユーザエージェントによって発行された後にBYEの間そうあいまいさがあるだろうと、フォークの要求が同じのCSeqを持たなければなりません。
Example:
例：
CSeq: 4711 INVITE
CSeq：4711 INVITE
Date is a general-header field. Its syntax is:
日付は、一般ヘッダフィールドです。その構文は次のとおりです。
SIP-date = rfc1123-date
SIP-日= RFC1123-日
See [H14.19] for a definition of rfc1123-date. Note that unlike HTTP/1.1, SIP only supports the most recent RFC1123 [29] formatting for dates.
RFC1123最新の定義については[H14.19]を参照してください。 HTTP / 1.1とは異なり、SIPのみ[29]日付の書式最新のRFC1123をサポートしていることに注意してください。
The Date header field reflects the time when the request or response is first sent. Thus, retransmissions have the same Date header field value as the original.
日付ヘッダーフィールドは、要求または応答が最初に送信された時刻を反映しています。したがって、再送信は元と同じ日ヘッダーフィールド値を有します。
The Date header field can be used by simple end systems
without a battery-backed clock to acquire a notion of
current time.
The Encryption general-header field specifies that the content has been encrypted. Section 13 describes the overall SIP security architecture and algorithms. This header field is intended for end-to-end encryption of requests and responses. Requests are encrypted based on the public key belonging to the entity named in the To header field. Responses are encrypted based on the public key conveyed in the Response-Key header field. Note that the public keys themselves may not be used for the encryption. This depends on the particular algorithms used.
暗号一般ヘッダフィールドは、コンテンツが暗号化されていることを指定します。セクション13は、全体的なSIPのセキュリティアーキテクチャとアルゴリズムを説明します。このヘッダーフィールドは、要求と応答のエンドツーエンドの暗号化のために意図されます。リクエストがToヘッダーフィールドで指定されたエンティティに属する公開鍵に基づいて暗号化されています。応答は、応答キーヘッダフィールドで搬送公開鍵に基づいて暗号化されています。公開鍵自体が暗号化に使用されないことに注意してください。これは、使用される特定のアルゴリズムに依存します。
For any encrypted message, at least the message body and possibly other message header fields are encrypted. An application receiving a request or response containing an Encryption header field decrypts the body and then concatenates the plaintext to the request line and headers of the original message. Message headers in the decrypted part completely replace those with the same field name in the plaintext part. (Note: If only the body of the message is to be encrypted, the body has to be prefixed with CRLF to allow proper concatenation.) Note that the request method and Request-URI cannot be encrypted.
任意の暗号化されたメッセージのために、少なくともメッセージ本体およびおそらく他のメッセージヘッダフィールドは、暗号化されています。暗号化ヘッダフィールドを含む要求または応答を受信したアプリケーションは、本体を解読した後、リクエストラインと元のメッセージのヘッダに平文を連結します。復号化された部分でのメッセージヘッダは完全に平文の部分で同じフィールド名を持つものを交換してください。 （注：メッセージの本文のみを暗号化する場合は、本体は、適切な連結を可能にするためにCRLFを前置しなければならない。）リクエストメソッドとRequest-URIは、暗号化することができないことに留意されたいです。
Encryption only provides privacy; the recipient has no
guarantee that the request or response came from the party
listed in the From message header, only that the sender
used the recipient's public key. However, proxies will not
be able to modify the request or response.
Encryption = "Encryption" ":" encryption-scheme 1*SP #encryption-params encryption-scheme = token encryption-params = token "=" ( token | quoted-string )
暗号化= "暗号化" "：" 暗号化スキーム1 *のSP＃暗号-のparams暗号化スキーム=トークン暗号-のparams =トークン "="（トークン|引用符で囲まれた文字列）
The token indicates the form of encryption used; it is described in section 13.
トークンは、使用する暗号化の形式を示します。これは、セクション13に記載されています。
The example in Figure 10 shows a message encrypted with ASCII-armored PGP that was generated by applying "pgp -ea" to the payload to be encrypted.
図10の例では、暗号化されるペイロードに「PGPの-ea」を適用することによって生成されたASCII装甲PGPで暗号化されたメッセージを示しています。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: <sip:a.g.bell@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com> Call-ID: 187602141351@worcester.bell-telephone.com Content-Length: 885 Encryption: PGP version=2.6.2,encoding=ascii
ベル@ワトソン：からSIP / 2.0 / UDP 169.130.12.5：watson@boston.bell-telephone.com SIP / 2.0経由：SIPのINVITE <一口：agbell@bell-telephone.com>へ：TAワトソン<一口telephone.com>コール-IDを：187602141351@worcester.bell-telephone.comのContent-Length：885暗号化：PGPバージョン= 2.6.2、エンコーディング= ASCII
hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 z8X9N4MhMyXEVuC9rt8/AUhmVQ== =bOW+
hQEMAxkp5GPd + j5xAQf / ZDIfGD / PDOM1wayvwdQAKgGgjmZWe + MTy9NEX8O25Red H0 / pyrd / + DV5C2BYs7yzSOSXaj1C / TTK / 4do6rtjhP8QA3vbDdVdaFciwEVAcuXs ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA zPVGq1VQg83b99zPzIxRdlZ + K7 + bAnu8Rtu + ohOCMLV3TPXbyp + err1YiThCZHIu X9dOVj3CMjCP66RSHa / ea0wYTRRNYA / G + kdP8DSUcqYAAAE / hZPX6nFIqk7AVnf6 IpWHUPTelNUJpzUp5Ou + Q + / 5P7ZAsn cSAuF2YWtVjCf + SQmBR13p2EYYWHoxlA2 / GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP + / yvRqFJtDGD / V3S ++ G2R + ViVYJO Z / lxGUZaM4IWBCf + 4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP + 6vGOFti1Ak4kmEz0vM / Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY / EwH2 z8X9N4MhMyXEVuC9rt8 / AUhmVQ == =弓+
Figure 10: PGP Encryption Example
図10：PGP暗号化の例
Since proxies can base their forwarding decision on any combination of SIP header fields, there is no guarantee that an encrypted request "hiding" header fields will reach the same destination as an otherwise identical un-encrypted request.
プロキシは、SIPヘッダフィールドの任意の組み合わせに、その転送決定を基づかことができるので、ヘッダフィールドを「隠す」暗号化された要求は、他の点では同一の非暗号化された要求と同じ宛先に到達するという保証はありません。
The Expires entity-header field gives the date and time after which the message content expires.
エンティティヘッダフィールドは、メッセージの内容の有効期限が切れた後の日付と時間を与える有効期限。
This header field is currently defined only for the REGISTER and INVITE methods. For REGISTER, it is a request and response-header field. In a REGISTER request, the client indicates how long it wishes the registration to be valid. In the response, the server indicates the earliest expiration time of all registrations. The server MAY choose a shorter time interval than that requested by the client, but SHOULD NOT choose a longer one.
このヘッダーフィールドは、現在のみREGISTERおよび方法をINVITEに定義されています。 REGISTERためには、リクエストとレスポンス・ヘッダー・フィールドです。 REGISTERリクエストでは、クライアントは、それが有効であるために登録を希望する期間を示します。応答では、サーバーはすべての登録の早い有効期限を示します。サーバは、クライアントから要求されたものよりも短い時間間隔を選ぶかもしれが、より長いものを選択すべきではありません。
For INVITE requests, it is a request and response-header field. In a request, the caller can limit the validity of an invitation, for example, if a client wants to limit the time duration of a search or a conference invitation. A user interface MAY take this as a hint to leave the invitation window on the screen even if the user is not currently at the workstation. This also limits the duration of a search. If the request expires before the search completes, the proxy returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily) response, a server can advise the client of the maximal duration of the redirection.
INVITE要求の場合、それはリクエストとレスポンス・ヘッダー・フィールドです。要求では、呼び出し側は、クライアントが検索や会議の招待状の期間を制限したい場合には、例えば、招待状の有効性を制限することができます。ユーザーインターフェースは、ユーザーがワークステーションで現在ない場合であっても、画面上の招待状の窓を残すためのヒントとして、このかかる場合があります。これは、検索の継続時間を制限します。検索が完了する前に、要求が期限切れになった場合、プロキシは408（要求タイムアウト）状態を返します。 302（一時的に移動）に応じて、サーバーは、リダイレクトの最大期間のクライアントに助言することができます。
The value of this field can be either a SIP-date or an integer number of seconds (in decimal), measured from the receipt of the request. The latter approach is preferable for short durations, as it does not depend on clients and servers sharing a synchronized clock. Implementations MAY treat values larger than 2**32-1 (4294967295 or 136 years) as equivalent to 2**32-1.
このフィールドの値は、SIP-日付または要求の受信から測定した（10進数）秒の整数のいずれかであることができます。それが同期したクロックを共有し、クライアントとサーバに依存しないよう後者のアプローチは、短い期間のために好適です。実装は2 ** 32-1と同等として2 ** 32-1（4294967295または136年）よりも値が大きく扱うかもしれ。
Expires = "Expires" ":" ( SIP-date | delta-seconds )
"（|デルタ秒SIP-日）：=" "有効期限" 有効期限
Two examples of its use are
その使用の2つの例は、
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: 5
有効期限：木、1994年12月1日16時00分00秒GMT有効期限：5
Requests and responses MUST contain a From general-header field, indicating the initiator of the request. The From field MAY contain the "tag" parameter. The server copies the From header field from the request to the response. 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.
要求と応答は、要求の開始を示す、一般的なヘッダフィールドを含有しなければなりません。フィールドから「タグ」パラメータを含むかもしれ。応答への要求からヘッダフィールドからサーバにコピー。オプションの「ディスプレイ名」は、ヒト・ユーザ・インターフェースによってレンダリングされることを意味します。クライアントのアイデンティティが隠されたままにする場合、システムは、表示名「匿名」を使用すべきです。
The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers" elements. A server that receives a SIP-URL with these elements removes them before further processing.
SIP-URLは、 "トランスポート・PARAM"、 "MADDR-PARAM"、 "TTL-PARAM"、または "ヘッダ" の要素が含まれてはなりません。これらの要素とのSIP-URLを受信するサーバーは、さらに処理する前にそれらを削除します。
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.
「表示名」は空であっても、「ADDR-specは」カンマ、疑問符、またはセミコロンが含まれている場合は、「名前-addrに」フォームを使用しなければなりません。
From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
addr-params = tag-param
tag-param = "tag=" UUID
UUID = 1*( hex | "-" )
Examples:
例：
From: "A. G. Bell" <sip:agb@bell-telephone.com> From: sip:+12125551212@server.phone2net.com From: Anonymous <sip:c8oqz84zk7z@privacy.org>
From： "A. G.ベル" <一口：agb@bell-telephone.com>から：SIP：+12125551212@server.phone2net.comから：匿名<SIP：c8oqz84zk7z@privacy.org>
The "tag" MAY appear in the From field of a request. It MUST be present when it is possible that two instances of a user sharing a SIP address can make call invitations with the same Call-ID.
「タグ」は、要求のFromフィールドに表示されることがあります。 SIPアドレスを共有するユーザーの2つのインスタンスが同じCall-IDを持つコールの招待状を作ることができることは可能であるとき、それは存在しなければなりません。
The "tag" value MUST be globally unique and cryptographically random with at least 32 bits of randomness. A single user maintains the same tag throughout the call identified by the Call-ID.
「タグ」の値は、ランダムの、少なくとも32ビットのグローバル一意と暗号ランダムでなければなりません。 1人のユーザーがコール-IDで識別される呼び出しを通じて同じタグを維持しています。
Call-ID, To and From are needed to identify a call leg.
The distinction between call and call leg matters in calls
with multiple responses to a forked request. The format is
similar to the equivalent RFC 822 [24] header, but with a
URI instead of just an email address.
A client uses the Hide request header field to indicate that it wants the path comprised of the Via header fields (Section 6.40) to be hidden from subsequent proxies and user agents. It can take two forms: Hide: route and Hide: hop. Hide header fields are typically added by the client user agent, but MAY be added by any proxy along the path.
クライアントは、Viaヘッダフィールド（セクション6.40）からなるパスが後続のプロキシとユーザエージェントから隠すことを望むことを示すために、非表示要求ヘッダフィールドを使用します。隠す：ルートと隠す：ホップそれは2つの形態を取ることができます。隠すヘッダフィールドは、典型的には、クライアント・ユーザ・エージェントによって追加されるが、経路に沿った任意のプロキシによって追加されるかもしれません。
If a request contains the "Hide: route" header field, all following proxies SHOULD hide their previous hop. If a request contains the "Hide: hop" header field, only the next proxy SHOULD hide the previous hop and then remove the Hide option unless it also wants to remain anonymous.
要求が含まれている場合は、「隠す：ルート」ヘッダフィールドを、以下のすべてのプロキシがその前のホップを非表示にします。リクエストは「隠す：ホップ」が含まれている場合ヘッダフィールドを、唯一の次のプロキシは、前のホップを非表示にすると、それはまた、匿名のままにしたいと考えていない限り、非表示オプションを削除してください。
A server hides the previous hop by encrypting the "host" and "port" parts of the top-most Via header field with an algorithm of its choice. Servers SHOULD add additional "salt" to the "host" and "port" information prior to encryption to prevent malicious downstream proxies from guessing earlier parts of the path based on seeing identical encrypted Via headers. Hidden Via fields are marked with the "hidden" Via option, as described in Section 6.40.
サーバが「ホスト」との「ポート」の部分を暗号化することで、前のホップを隠し一番上のその選択のアルゴリズムとViaヘッダーフィールド。サーバーは、ヘッダーで暗号化の同一見に基づいてパスの以前の部分を推測するから悪質な下流のプロキシを防ぐために、暗号化の前に、「ホスト」と「ポート」の情報を追加、「塩」を追加する必要があります。フィールドを経由して隠し、セクション6.40で説明したように、オプションで「隠された」とマークされています。
A server that is capable of hiding Via headers MUST attempt to decrypt all Via headers marked as "hidden" to perform loop detection. Servers that are not capable of hiding can ignore hidden Via fields in their loop detection algorithm.
Viaヘッダーに隠れてすることができ、サーバは、ループ検出を実行するために、「隠された」とマークされた全てのViaヘッダを解読しようとしなければなりません。隠れすることができないサーバーは、そのループ検出アルゴリズムのフィールドを経由して隠れて無視することができます。
If hidden headers were not marked, a proxy would have to
decrypt all headers to detect loops, just in case one was
encrypted, as the Hide: Hop option may have been removed
along the way.
A host MUST NOT add such a "Hide: hop" header field unless it can guarantee it will only send a request for this destination to the same next hop. The reason for this is that it is possible that the request will loop back through this same hop from a downstream proxy. The loop will be detected by the next hop if the choice of next hop is fixed, but could loop an arbitrary number of times otherwise.
それが唯一の同じ次ホップにこの先の要求を送信します保証することができない限り、ヘッダフィールド：ホストは、このような「ホップを隠す」を追加してはなりません。この理由は、それが、要求が戻って下流のプロキシからこの同じホップをループすることが可能であるということです。ネクストホップの選択は固定され、それ以外ループ任意の回数をできればループが次のホップによって検出されます。
A client requesting "Hide: route" can only rely on keeping the request path private if it sends the request to a trusted proxy. Hiding the route of a SIP request is of limited value if the request results in data packets being exchanged directly between the calling and called user agent.
「隠す：ルート」を要求しているクライアントは、信頼できるプロキシにリクエストを送信した場合のみ、プライベート要求パスを保つことに頼ることができます。データパケット内の要求の結果が発呼および着呼ユーザーエージェントとの間で直接交換される場合、SIP要求の経路を非表示にする限定された値です。
The use of Hide header fields is discouraged unless path privacy is truly needed; Hide fields impose extra processing costs and restrictions for proxies and can cause requests to generate 482 (Loop Detected) responses that could otherwise be avoided.
パスのプライバシーが真に必要とされない限り隠すヘッダフィールドの使用が推奨され、フィールドは、プロキシのための余分な処理コストと制限を課し、それ以外の場合は回避することができる482（ループ検出）の応答を生成するための要求を引き起こす可能性があります非表示にします。
The encryption of Via header fields is described in more detail in Section 13.
Viaヘッダフィールドの暗号化は、セクション13においてより詳細に記載されています。
The Hide header field has the following syntax:
隠すヘッダフィールドの構文は次のとおりです。
Hide = "Hide" ":" ( "route" | "hop" )
隠す= "隠す" "："（ "ルート" | "ホップ"）
The Max-Forwards request-header field may 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 which appears to be failing or looping in mid-chain.
マックスを転送リクエストヘッダフィールドは、次のダウンストリームのサーバに要求を転送することができるプロキシまたはゲートウェイの数を制限するために、任意のSIPメソッドで使用されてもよいです。クライアントは、中鎖に失敗またはループしているように見えるリクエストチェーンをトレースしようとしているときにも役立ちます。
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
マックス・フォワード=「マックス・フォワード」「：」1 * DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message is allowed to be forwarded.
最大転送した値は、この要求メッセージを転送することが許可されている残り回数を示す10進整数です。
Each proxy or gateway recipient of a request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request. Instead, for the OPTIONS and REGISTER methods, it MUST respond as the final recipient. For all other methods, the server returns 483 (Too many hops).
Max-Forwardsヘッダーフィールドを含むリクエストの各プロキシまたはゲートウェイ受信者は、要求を転送する前にその値を確認して更新しなければなりません。受信された値がゼロ（0）である場合、受信者は、要求を転送してはいけません。代わりに、OPTIONSおよびREGISTER法のために、それは最終的に受信者として応答しなければなりません。他のすべてのメソッドの場合、サーバは483（ホップ数が多すぎ）を返します。
If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).
受信された最大転送した値がゼロよりも大きい場合、転送されたメッセージは、一（1）だけ減分値で更新最大転送しフィールドを含まなければなりません。
Example:
例：
Max-Forwards: 6
マックス・フォワード：6
The Organization general-header field conveys the name of the organization to which the entity issuing the request or response belongs. It MAY also be inserted by proxies at the boundary of an organization.
組織一般的なヘッダフィールドは、要求または応答を発行するエンティティが所属する組織の名前を伝えます。また、組織の境界でのプロキシによって挿入されてもよいです。
The field MAY be used by client software to filter calls.
フィールドには、呼び出しをフィルタリングするために、クライアントソフトウェアによって使用されるかもしれません。
Organization = "Organization" ":" *TEXT-UTF8
組織= "組織" "：" * TEXT-UTF8
The Priority request-header field indicates the urgency of the request as perceived by the client.
クライアントによって知覚される優先リクエストヘッダフィールドは、要求の緊急性を示しています。
Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal"
| "non-urgent"
It is RECOMMENDED that the value of "emergency" only be used when life, limb or property are in imminent danger.
生命、身体または財産が差し迫って危険にさらされている時に「緊急」の値のみが使用することをお勧めします。
Examples:
例：
Subject: A tornado is heading our way! Priority: emergency
件名：竜巻は、私たちの道を向かっています！優先度：緊急
Subject: Weekend plans Priority: non-urgent
件名：週末の計画の優先順位：非緊急
These are the values of RFC 2076 [30], with the addition of "emergency".
これらは、「緊急」を加えて、RFC 2076 [30]の値です。
The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.
プロキシ認証レスポンス・ヘッダー・フィールドは、407（プロキシ認証が必要）応答の一部として含まれなければなりません。フィールド値はこのRequest-URIに対してプロキシに適用できる認証スキームとパラメータを示し挑戦で構成されています。
Unlike its usage within HTTP, the Proxy-Authenticate header MUST be passed upstream in the response to the UAC. In SIP, only UAC's can authenticate themselves to proxies.
HTTP内での使用とは異なり、プロキシ認証ヘッダはUACに応答して上流渡さなければなりません。 SIPでは、唯一のUACのは、プロキシに自身を認証することができます。
The syntax for this header is defined in [H14.33]. See 14 for further details on its usage.
このヘッダの構文は[H14.33]で定義されています。その使用法の更なる詳細については14を参照してください。
A client SHOULD cache the credentials used for a particular proxy server and realm for the next request to that server. Credentials are, in general, valid for a specific value of the Request-URI at a particular proxy server. If a client contacts a proxy server that has required authentication in the past, but the client does not have credentials for the particular Request-URI, it MAY attempt to use the most-recently used credential. The server responds with 401 (Unauthorized) if the client guessed wrong.
クライアントは、そのサーバーに次の要求のための特定のプロキシサーバとレルムの使用する資格情報をキャッシュすべきです。資格情報は、一般的には、特定のプロキシサーバで要求URIの特定の値のために有効です。クライアントは、過去に認証を必要としていたプロキシサーバーが、特定のRequest-URIのための資格情報を持っていないクライアント場合、それは最も最近使用した資格情報を使用しようとするかもしれません。クライアントが間違った推測場合、サーバは401（無許可）で応答します。
This suggested caching behavior is motivated by proxies
restricting phone calls to authenticated users. It seems
likely that in most cases, all destinations require the
same password. Note that end-to-end authentication is
likely to be destination-specific.
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The 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.
プロキシ認証リクエストヘッダフィールドは、クライアントが認証を必要とするプロキシにそれ自体（又はそのユーザ）を識別することを可能にします。プロキシ認証フィールド値は、プロキシおよび/または要求されたリソースのレルムのユーザエージェントの認証情報を含む資格情報から成ります。
Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy- Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
許可とは異なり、Proxy-Authorizationヘッダフィールドは、Proxy-認証フィールドを使用して認証を要求し、次のアウトバウンドプロキシに適用されます。複数のプロキシをチェーンで使用される場合、Proxy-Authorizationヘッダフィールドは、認証情報を受信するように期待していた最初のアウトバウンドプロキシによって消費されます。それはプロキシが協調与えられた要求を認証するメカニズムがある場合、プロキシは、次のプロキシにクライアント要求から資格情報を中継することができます。
See [H14.34] for a definition of the syntax, and section 14 for a discussion of its usage.
構文の定義、およびその使用方法の説明についてはセクション14のために[H14.34]を参照してください。
The Proxy-Require header field is used to indicate proxy-sensitive features that MUST be supported by the proxy. Any Proxy-Require header field features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client if not supported. Proxy servers treat this field identically to the Require field.
プロキシ要求ヘッダーフィールドは、プロキシによってサポートされなければならないプロキシ感受性の特徴を示すために使用されます。サポートされていない場合は、プロキシによってサポートされていないすべてのプロキシ-Requireヘッダーフィールドの機能は負のクライアントへのプロキシによって承認されなければなりません。プロキシサーバーは、同じように要求するフィールドにこのフィールドを扱います。
See Section 6.30 for more details on the mechanics of this message and a usage example.
このメッセージと使用例の仕組みの詳細については、セクション6.30を参照してください。
The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. It contains a globally reachable Request-URI that identifies the proxy server. Each proxy server adds its Request-URI to the beginning of the list.
レコードルートリクエストとレスポンスヘッダフィールドは、同じコールレッグのための後続の要求の経路であることに主張任意プロキシによって要求に追加されます。これは、プロキシサーバーを識別するグローバルに到達可能のRequest-URIが含まれています。各プロキシサーバーは、リストの先頭にその要求URIを追加します。
The server copies the Record-Route header field unchanged into the response. (Record-Route is only relevant for 2xx responses.)
応答にそのままサーバにコピーRecord-Routeヘッダーフィールド。 （レコード・ルートは、2xx応答のためにのみ関係します。）
The calling user agent client copies the Record-Route header into a Route header field of subsequent requests within the same call leg, reversing the order of requests, so that the first entry is closest to the user agent client. If the response contained a Contact header field, the calling user agent adds its content as the last Route header. Unless this would cause a loop, any client MUST send any subsequent requests for this call leg to the first Request-URI in the Route request header field and remove that entry.
最初のエントリは、ユーザエージェントクライアントに最も近くなるように呼び出すユーザエージェントクライアントのコピーはレコード・ルートは、要求の順序を逆に、同じコールレッグ内の後続のリクエストのRouteヘッダーフィールドにヘッダー。応答はContactヘッダーフィールドが含まれていた場合、呼び出したユーザエージェントは、最後のRouteヘッダとしてその内容を追加します。これは、ループの原因となる場合を除き、任意のクライアントは、ルートリクエストヘッダフィールドに最初のRequest-URIに、このコールレッグのための任意の後続の要求を送信し、そのエントリを削除する必要があります。
The calling user agent MUST NOT use the Record-Route header field in requests that contain Route header fields.
呼び出しユーザエージェントは、Routeヘッダーフィールドを含む要求にRecord-Routeヘッダーフィールドを使用してはなりません。
Some proxies, such as those controlling firewalls or in an
automatic call distribution (ACD) system, need to maintain
call state and thus need to receive any BYE and ACK packets
for the call.
The Record-Route header field has the following syntax:
Record-Routeヘッダーフィールドの構文は次のとおりです。
Record-Route = "Record-Route" ":" 1# name-addr
レコードルート= "レコード・ルート" "：" 1＃名前-addrに
Proxy servers SHOULD use the "maddr" URL parameter containing their address to ensure that subsequent requests are guaranteed to reach exactly the same server.
プロキシサーバーは、後続の要求がまったく同じサーバーに到達するために保証されていることを確認するために自分のアドレスを含む「MADDR」URLのパラメータを使用する必要があります。
Example for a request that has traversed the hosts ieee.org and bell-telephone.com , in that order:
そのために、ieee.orgとbell-telephone.comホストを横断した要求の例：
Record-Route: <sip:a.g.bell@bell-telephone.com>, <sip:a.bell@ieee.org>
レコードルート：<SIP：a.g.bell@bell-telephone.com>、<SIP：a.bell@ieee.org>
The Require request-header field is used by clients to tell user agent servers about options that the client expects the server to support in order to properly process the request. If a server does not understand the option, it MUST respond by returning status code 420 (Bad Extension) and list those options it does not understand in the Unsupported header.
必須リクエストヘッダフィールドは、クライアントが、サーバがリクエストを適切に処理するためにサポートする予定のオプションについてのユーザエージェントサーバに伝えるためにクライアントによって使用されます。サーバがオプションを理解していない場合は、ステータスコード420（悪い拡張）を返すことによって応答し、それがサポートされていないヘッダに理解していないこれらのオプションをリストする必要があります。
Require = "Require" ":" 1#option-tag
=「「必要」が必要です：」1つの＃オプションタグ
Example:
例：
C->S: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: com.example.billing Payment: sheep_skins, conch_shells
C-> S：INVITE SIP：watson@bell-telephone.com SIP / 2.0要求：com.example.billing支払：sheep_skins、conch_shells
S->C: SIP/2.0 420 Bad Extension Unsupported: com.example.billing
S-> C：SIP / 2.0 420悪い拡張サポートされていない：com.example.billing
This is to make sure 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.
Proxy and redirect servers MUST ignore features that are not understood. If a particular extension requires that intermediate devices support it, the extension MUST be tagged in the Proxy-Require field as well (see Section 6.28).
プロキシとリダイレクトサーバーは、理解されていない機能を無視しなければなりません。特定の拡張は、中間デバイスがそれをサポートする必要がある場合、エクステンションは、（セクション6.28を参照）、ならびにフィールドをプロキシ要求にタグ付けされなければなりません。
The Response-Key request-header field can be used by a client to request the key that the called user agent SHOULD use to encrypt the response with. The syntax is:
応答キーリクエストヘッダフィールドは、呼び出されたユーザエージェントがで応答を暗号化するために使用する必要があるキーを要求するためにクライアントで使用することができます。構文は次のとおりです。
Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = token "=" ( token | quoted-string )
The "key-scheme" gives the type of encryption to be used for the response. Section 13 describes security schemes.
「キー・スキームは、」応答に使用する暗号化の種類を提供します。第13節は、セキュリティ方式について説明します。
If the client insists that the server return an encrypted response, it includes a
クライアントは、サーバが暗号化された応答を返すことを主張した場合、それは、
Require: org.ietf.sip.encrypt-response
必要：org.ietf.sip.encrypt応答
header field in its request. If the server cannot encrypt for whatever reason, it MUST follow normal Require header field procedures and return a 420 (Bad Extension) response. If this Require header field is not present, a server SHOULD still encrypt if it can.
その要求のヘッダフィールド。サーバが何らかの理由で暗号化することができない場合、通常はヘッダフィールド手順を必要に従い、420（悪い拡張）応答を返さなければなりません。このRequireヘッダーフィールドが存在しない場合はそれができるならば、サーバはまだ暗号化する必要があります。
The Retry-After general-header field can be used with a 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), 600 (Busy), or 603 (Decline) response to indicate when the called party anticipates being available again. The value of this field can be either an SIP-date or an integer number of seconds (in decimal) after the time of the response.
リトライ後、一般的なヘッダフィールドは、サービスを要求するクライアントへと（見つかりません）404、600（BUSY）、または603で利用できないと予想される時間の長さを示すために503（サービス利用不可）応答と共に使用することができます着信側が再び利用可能見込んでいたときに示すために、（下落）応答。このフィールドの値は、応答の時間後にSIP-日付または（10進数）秒の整数のいずれかであり得ます。
A REGISTER request MAY include this header field when deleting registrations with "Contact: * ;expires: 0". The Retry-After value then indicates when the user might again be reachable. The registrar MAY then include this information in responses to future calls.
「：;：0期限切れになる*連絡先」で登録を削除するときREGISTERリクエストは、このヘッダーフィールドを含んでいてもよいです。ユーザーが再び到達可能性がある場合の再試行-後値は示しています。レジストラは、将来の呼び出しに応答して、この情報を含むことができます。
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.
オプションのコメントは、コールバックの時間に関する追加情報を示すために使用することができます。オプションの「期間」パラメータは、着信側が可用性の初期時点から始まる到達可能になりますどのくらいを示しています。何durationパラメータが指定されていない場合は、サービスが無期限に利用可能であると仮定されます。
Retry-After = "Retry-After" ":" ( SIP-date | delta-seconds )
[ comment ] [ ";" "duration" "=" delta-seconds ]
Examples of its use are
その使用の例は、
Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)
リトライ後：月、1997年7月21日夜六時48分34秒GMT（私は会議中です）
Retry-After: Mon, 01 Jan 9999 00:00:00 GMT (Dear John: Don't call me back, ever) Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600 Retry-After: 120
リトライ後：月、1月1日00:00:00 GMT 9999は、（親愛なるジョンは：これまでに、戻って私を呼び出さないでください）再試行-後：金、1997年9月26日午後9時00分00秒GMT;期間= 3600リトライ-後：120
In the third example, the callee is reachable for one hour starting at 21:00 GMT. In the last example, the delay is 2 minutes.
第3の例では、被呼者は、一時間21:00 GMTに開始するための到達可能です。最後の例では、遅延は2分です。
The Route request-header field determines the route taken by a request. Each host removes the first entry and then proxies the request to the host listed in that entry, also using it as the Request-URI. The operation is further described in Section 6.29.
ルートリクエストヘッダフィールドは、リクエストによって取られる経路を決定します。各ホストは、最初のエントリを削除した後も、リクエストURIとしてそれを使用して、そのエントリにリストされたホストへの要求をプロキシ。動作はさらに、セクション6.29に記載されています。
The Route header field has the following syntax:
Routeヘッダーフィールドの構文は次のとおりです。
Route = "Route" ":" 1# name-addr
ルート= "ルート" "：" 1＃名-addrに
The Server response-header field contains information about the software used by the user agent server to handle the request. The syntax for this field is defined in [H14.39].
サーバーレスポンスヘッダフィールドは、リクエストを処理するために、ユーザエージェントサーバで使用されているソフトウェアに関する情報が含まれています。このフィールドの構文は[H14.39]で定義されています。
This is intended to provide a summary, or to indicate the nature, of the call, allowing call filtering without having to parse the session description. (Also, the session description does not have to use the same subject indication as the invitation.)
これは、要約を提供するために、またはセッション記述を解析することなく、コールフィルタリングが可能、コールの性質を、示すことを意図しています。 （また、セッション記述は招待と同じサブジェクト表示を使用する必要はありません。）
Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8
件名=（ "件名" | "S"） "：" * TEXT-UTF8
Example:
例：
Subject: Tune in - they are talking about your work!
件名：チューンで - 彼らはあなたの仕事について話しています！
The timestamp general-header field describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and it MAY use any timescale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that have elapsed since it has received the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the timeout value for retransmissions.
クライアントがサーバに要求を送信したときのタイムスタンプ一般ヘッダフィールドについて説明します。タイムスタンプの値は、クライアントだけに重要であり、それは、任意の時間スケールを使用するかもしれません。サーバは、このに関する正確な情報を持っている場合、それは要求を受信したから経過した秒数を示す浮動小数点数を追加し、まったく同じ値とMAYをエコーしなければなりません。タイムスタンプは、再送信のタイムアウト値を調整することができるように、サーバーへのラウンドトリップ時間を計算するために、クライアントによって使用されます。
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
Note that there MUST NOT be any LWS between a DIGIT and the decimal point.
DIGITと小数点の間に任意のLWSがあってはならないことに注意してください。
The To general-header field specifies recipient of the request, with the same SIP URL syntax as the From field.
一般的なヘッダフィールドのフィールドから同じSIPのURLの構文で、リクエストの受信者を指定します。
To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
Requests and responses MUST contain a To general-header field, indicating the desired recipient of the request. The optional "display-name" is meant to be rendered by a human-user interface. The UAS or redirect server copies the To header field into its response, and MUST add a "tag" parameter if the request contained more than one Via header field.
要求と応答は、要求の所望の受信者を示し、一般的なヘッダフィールドに含まれなければなりません。オプションの「ディスプレイ名」は、ヒト・ユーザ・インターフェースによってレンダリングされることを意味します。 UAS又はリダイレクトサーバコピーその応答にフィールドをヘッダし、要求がViaヘッダーフィールドつ以上が含まれている場合、「タグ」パラメータを追加しなければなりません。
If there was more than one Via header field, the request
was handled by at least one proxy server. Since the
receiver cannot know whether any of the proxy servers
forked the request, it is safest to assume that they might
have.
The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers" elements. A server that receives a SIP-URL with these elements removes them before further processing.
SIP-URLは、 "トランスポート・PARAM"、 "MADDR-PARAM"、 "TTL-PARAM"、または "ヘッダ" の要素が含まれてはなりません。これらの要素とのSIP-URLを受信するサーバーは、さらに処理する前にそれらを削除します。
The "tag" parameter serves as a general mechanism to distinguish multiple instances of a user identified by a single SIP URL. As proxies can fork requests, the same request can reach multiple instances of a user (mobile and home phones, for example). As each can respond, there needs to be a means to distinguish the responses from each at the caller. The situation also arises with multicast requests. The tag in the To header field serves to distinguish responses at the UAC. It MUST be placed in the To field of the response by each instance when there is a possibility that the request was forked at an intermediate proxy. The "tag" MUST be added by UAS, registrars and redirect servers, but MUST NOT be inserted into responses forwarded upstream by proxies. The "tag" is added for all definitive responses for all methods, and MAY be added for informational responses from a UAS or redirect server. All subsequent transactions between two entities MUST include the "tag" parameter, as described in Section 11.
「タグ」パラメータは、単一のSIP URLによって識別されたユーザの複数のインスタンスを区別するための一般的な機構として役立ちます。プロキシがリクエストをフォークのように、同じ要求は、（例えば、携帯電話や自宅電話）利用者の複数のインスタンスに到達することができます。それぞれが対応できるように、呼び出し側のそれぞれからの応答を区別するための手段が必要です。状況はまた、マルチキャスト要求を発生します。 Toヘッダーフィールド内のタグは、UACに応答を区別するのに役立ちます。要求が中間プロキシで二股している可能性がある場合には、各インスタンスによって応答のToフィールドに置かれなければなりません。 「タグ」はUAS、レジストラが追加され、サーバーにリダイレクトしますが、プロキシによってアップストリーム転送応答に挿入してはならないしなければなりません。 「タグ」は、すべてのメソッドのためのすべての決定的な応答のために追加され、UASからの情報の応答を追加したり、サーバーにリダイレクトされるかもしれません。セクション11で説明したように2つのエンティティ間のすべての後続のトランザクションは、「タグ」パラメータを含まなければなりません。
See Section 6.21 for details of the "tag" parameter.
「タグ」パラメータの詳細については、セクション6.21を参照してください。
The "tag" parameter in To headers is ignored when matching responses to requests that did not contain a "tag" in their To header.
ヘッダに自分の中に「タグ」を含んでいなかった要求に対する応答を照合する際に、ヘッダーに「タグ」パラメータは無視されます。
A SIP server returns a 400 (Bad Request) response if it receives a request with a To header field containing a URI with a scheme it does not recognize.
それが認識されない方式でURIを含むフィールドをヘッダのあるリクエストを受信した場合、SIPサーバは、400（悪いRequest）応答を返します。
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.
「表示名」は空であっても、「ADDR-specは」カンマ、疑問符、またはセミコロンが含まれている場合は、「名前-addrに」フォームを使用しなければなりません。
The following are examples of valid To headers:
ヘッダへの有効な例は次のとおりです。
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 To: sip:+12125551212@server.phone2net.com
To：演算子<SIP：operator@cs.columbia.edu>;タグ= 287447へ：SIP：+12125551212@server.phone2net.com
Call-ID, To and From are needed to identify a call leg. The distinction between call and call leg matters in calls with multiple responses from a forked request. The "tag" is added to the To header field in the response to allow forking of future requests for the same call by proxies, while addressing only one of the possibly several responding user agent servers. It also allows several instances of the callee to send requests that can be distinguished.
コールIDを、コールレッグを識別するために必要なにしてから。フォーク要求から複数の応答と通話中のコールとコールレッグ事項の区別。 「タグ」は、おそらくいくつかの応答ユーザエージェントサーバの一つだけに対応しつつ、プロキシによって同じ呼び出しのための今後の要求のフォーク許可するように反応してToヘッダーフィールドに追加されます。また、呼び出し先の複数のインスタンスを区別することができますリクエストを送信することができます。
The Unsupported response-header field lists the features not supported by the server. See Section 6.30 for a usage example and motivation.
サポートされていないレスポンスヘッダフィールドは、サーバでサポートされていない機能を示します。使用例と動機については、セクション6.30を参照してください。
Syntax:
構文：
Unsupported = "Unsupported" ":" 1#option-tag
サポートされていない「=「サポートされていない」：」1＃オプションタグ
The User-Agent general-header field contains information about the client user agent originating the request. The syntax and semantics are defined in [H14.42].
User-Agent一般ヘッダフィールドは、リクエスト元のクライアント・ユーザー・エージェントに関する情報が含まれています。構文とセマンティクスは[H14.42]で定義されています。
The Via field indicates the path taken by the request so far. This prevents request looping and ensures replies take the same path as the requests, which assists in firewall traversal and other unusual routing situations.
Viaフィールドには、これまでに要求が取る経路を示しています。これは、要求のループを防止し、応答がファイアウォールトラバーサルおよびその他の異常なルーティング状況で支援を要求、同じパスを取ることが保証されます。
The client originating the request MUST insert into the request a Via field containing its host name or network address and, if not the default port number, the port number at which it wishes to receive responses. (Note that this port number can differ from the UDP source port number of the request.) A fully-qualified domain name is RECOMMENDED. Each subsequent proxy server that sends the request onwards MUST add its own additional Via field before any existing Via fields. A proxy that receives a redirection (3xx) response and then searches recursively, MUST use the same Via headers as on the original proxied request.
デフォルト以外のポート番号は、ポート番号はその時、それは応答を受信したい場合は、要求元のクライアントは、要求にそのホスト名またはネットワークアドレスを含むViaフィールドを挿入しなければなりません。 （このポート番号は、要求のUDPソースポート番号と異なることに注意してください。）完全修飾ドメイン名が推奨されます。以降のリクエストを送信し後続の各プロキシサーバーは、既存のViaフィールドの前に、独自の追加のViaフィールドを追加しなければなりません。 、リダイレクション（3XX）応答を受信した後、再帰的に検索プロキシは、元のプロキシリクエストに同じのViaヘッダを使用しなければなりません。
A proxy SHOULD check the top-most Via header field to ensure that it contains the sender's correct network address, as seen from that proxy. If the sender's address is incorrect, the proxy MUST add an additional "received" attribute, as described 6.40.2.
プロキシは、そのプロキシから分かるように、それは、送信者の正しいネットワークアドレスが含まれていることを確認するためにViaヘッダーフィールド最上位を確認する必要があります。送信者のアドレスが誤っている場合、プロキシは6.40.2を説明するように、追加のは、属性を「受信」を追加しなければなりません。
A host behind a network address translator (NAT) or
firewall may not be able to insert a network address into
the Via header that can be reached by the next hop beyond the NAT. Use of the received attribute allows SIP requests
to traverse NAT's which only modify the source IP address.
NAT's which modify port numbers, called Network Address
Port Translator's (NAPT) will not properly pass SIP when
transported on UDP, in which case an application layer
gateway is required. When run over TCP, SIP stands a better
chance of traversing NAT's, since its behavior is similar
to HTTP in this case (but of course on different ports).
A proxy sending a request to a multicast address MUST add the "maddr" parameter to its Via header field, and SHOULD add the "ttl" parameter. If a server receives a request which contained an "maddr" parameter in the topmost Via field, it SHOULD send the response to the multicast address listed in the "maddr" parameter.
マルチキャストアドレスにリクエストを送信するプロキシは、そのViaヘッダーフィールドに「maddrパラメータ」パラメータを追加しなければならない、と「TTL」パラメータを追加する必要があります。サーバーがフィールドを経由して、最上位の「MADDR」パラメータが含まれる要求を受信した場合、それは「MADDR」パラメータで指定されたマルチキャストアドレスに応答を送信すべきです。
If a proxy server receives a request which contains its own address in the Via header value, it MUST respond with a 482 (Loop Detected) status code.
プロキシサーバはViaヘッダ値の自身のアドレスが含まれている要求を受信した場合、それは482（ループ検出）のステータスコードで応じなければなりません。
A proxy server MUST NOT forward a request to a multicast group which already appears in any of the Via headers.
プロキシサーバはすでにのViaヘッダのいずれかに表示されたマルチキャストグループに要求を転送してはなりません。
This prevents a malfunctioning proxy server from causing
loops. Also, it cannot be guaranteed that a proxy server
can always detect that the address returned by a location
service refers to a host listed in the Via list, as a
single host may have aliases or several network interfaces.
Normally, every host that sends or forwards a SIP message adds a Via field indicating the path traversed. However, it is possible that Network Address Translators (NATs) changes the source address and port of the request (e.g., from net-10 to a globally routable address), in which case the Via header field cannot be relied on to route replies. To prevent this, a proxy SHOULD check the top-most Via header field to ensure that it contains the sender's correct network address, as seen from that proxy. If the sender's address is incorrect, the proxy MUST add a "received" parameter to the Via header field inserted by the previous hop. Such a modified Via header field is known as a receiver-tagged Via header field. An example is:
通常、送信またはSIPメッセージを転送するすべてのホストは、横断パスを示すViaフィールドを追加します。しかし、ネットワークトランスレータ（NATの）に対処することが可能であるViaヘッダーフィールドは、ルート返答上に依拠することができない場合に、要求（例えば、ネット10からのグローバルにルーティング可能なアドレス）の送信元アドレスとポートを変更します。これを防ぐために、プロキシはそのプロキシから分かるように、それは、送信者の正しいネットワークアドレスが含まれていることを確認するためにViaヘッダーフィールド最上位を確認する必要があります。送信者のアドレスが誤っている場合、プロキシは、前のホップで挿入Viaヘッダーフィールドに「受信」パラメータを追加する必要があります。そのようなヘッダフィールドを介して修飾された受信機タグViaヘッダーフィールドとして知られています。例は次のとおりです。
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060 Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3
経由：SIP / 2.0 / UDP erlang.bell-telephone.com:5060介し：SIP / 2.0 / UDP 10.0.0.1:5060;受信= 199.172.136.3
In this example, the message originated from 10.0.0.1 and traversed a NAT with the external address border.ieee.org (199.172.136.3) to reach erlang.bell-telephone.com. The latter noticed the mismatch, and added a parameter to the previous hop's Via header field, containing the address that the packet actually came from. (Note that the NAT border.ieee.org is not a SIP server.)
この例では、メッセージは、10.0.0.1から発信され、erlang.bell-telephone.comに到達するために、外部アドレスborder.ieee.org（199.172.136.3）でNATをトラバース。後者は不一致に気づいて、パケットが実際にから来たアドレスを含む、前のホップのViaヘッダーフィールドにパラメータを追加しました。 （NAT border.ieee.orgは、SIPサーバではないことに注意してください。）
Via header fields in responses are processed by a proxy or UAC according to the following rules:
応答のヘッダフィールドを介して、次の規則に従ってプロキシまたはUACによって処理されます。
1. The first Via header field should indicate the proxy or
client processing this response. If it does not, discard
the message. Otherwise, remove this Via field.
2. If there is no second Via header field, this response is destined for this client. Otherwise, the processing depends on whether the Via field contains a "maddr" parameter or is a receiver-tagged field:
2. Viaヘッダーフィールド何秒が存在しない場合は、この応答は、このクライアントのために運命づけられています。そうでなければ、処理は、Viaフィールドが「MADDR」パラメータが含まれているか、受信タグ付きフィールドであるかどうかによって異なります。
- If the second Via header field contains a "maddr"
parameter, send the response to the multicast address
listed there, using the port indicated in "sent-by", or
port 5060 if none is present. 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. For
robustness, responses MUST be sent to the address
indicated in the "maddr" parameter even if it is not a
multicast address.
- If the second Via header field does not contain a "maddr" parameter and is a receiver-tagged field (Section 6.40.2), send the message to the address in the "received" parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is present.
- ヘッダーフィールドを介して第二が「MADDR」パラメータを含み、受信機タグフィールド（セクション6.40.2）でない場合は、ポートを使用して、パラメータを「受信」のアドレスにメッセージを送信する「送信に示され値、または何も存在しない場合は、ポート5060を使用して「-by。
- If neither of the previous cases apply, send the message to the address indicated by the "sent-by" value in the second Via header field.
- 以前のケースのどちらが適用される場合、「送信バイ」値第二のViaヘッダフィールド内で示されるアドレスにメッセージを送信します。
A UAS or redirect server sends a response based on one of the following rules:
UASまたはサーバーをリダイレクトするには、以下のいずれかのルールに基づいて応答を送信します。
o If the first Via header field in the request contains a
"maddr" parameter, send the response to the multicast address listed there, using the port indicated in "sent-by", or port
5060 if none is present. 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. For robustness, responses MUST
be sent to the address indicated in the "maddr" parameter even
if it is not a multicast address.
o If the address in the "sent-by" value of the first Via field differs from the source address of the packet, send the response to the actual packet source address, similar to the treatment for receiver-tagged Via header fields (Section 6.40.2).
「送信ごとの」第Viaフィールドの値のアドレスは、パケットの送信元アドレスと異なる場合、O、ヘッダフィールドを介して受信機タグの治療と同様、実際のパケットの送信元アドレスに応答を送る（セクション6.40 0.2）。
o If neither of these conditions is true, send the response to the address contained in the "sent-by" value. If the request was sent using TCP, use the existing TCP connection if available.
これらの条件のいずれにも該当しない場合、O、「送られたバイ」の値に含まれているアドレスへの応答を送信します。要求はTCPを使用して送信された場合は可能な場合は、既存のTCP接続を使用します。
The format for a Via header field is shown in Fig. 11. The defaults for "protocol-name" and "transport" are "SIP" and "UDP", respectively. The "maddr" parameter, designating the multicast address, and the "ttl" parameter, designating the time-to-live (TTL) value, are included only if the request was sent via multicast. The "received" parameter is added only for receiver-added Via fields (Section 6.40.2). For reasons of privacy, a client or proxy may wish to hide its Via information by encrypting it (see Section 6.22). The "hidden" parameter is included if this header field was hidden by the upstream proxy (see 6.22). Note that privacy of the proxy relies on the cooperation of the next hop, as the next-hop proxy will, by necessity, know the IP address and port number of the source host.
Viaヘッダーフィールドの形式は、「プロトコル名」と「輸送」のデフォルト値は、それぞれ、「SIP」および「UDP」である図11に示されています。生存時間（TTL）値を指定するマルチキャストアドレスを指定する「MADDR」パラメータ、そして「TTL」パラメータは、要求は、マルチキャストを介して送信された場合にのみ含まれています。 「受信」パラメータは、受信機の付加フィールドを介して（セクション6.40.2）のためにのみ添加されます。プライバシーの理由から、クライアントまたはプロキシ（セクション6.22を参照）、それを暗号化することによって、その経由の情報を非表示にすることがあります。このヘッダーフィールドは、上流側プロキシ（6.22を参照）によって隠された場合、「隠れた」パラメータが含まれています。ネクストホッププロキシは、必然的に、送信元ホストのIPアドレスとポート番号を知っているとプロキシのプライバシーは、次のホップの協力に依存していることに注意してください。
The "branch" parameter is included by every forking proxy. The token MUST be unique for each distinct request generated when a proxy forks. CANCEL requests MUST have the same branch value as the corresponding forked request. When a response arrives at the proxy it can use the branch value to figure out which branch the response corresponds to. A proxy which generates a single request (non-forking) MAY also insert the "branch" parameter. The identifier has to be unique only within a set of isomorphic requests.
「ブランチ」のパラメータは、すべてのフォークプロキシによって含まれています。トークンは、プロキシフォーク生成された各個別の要求に対して一意でなければなりません。 CANCELリクエストは、対応するフォーク要求と同じブランチ値を持たなければなりません。応答がプロキシに到着すると、それは、応答がに対応する枝を把握する分岐値を使用することができます。単一の要求（非フォーク）を生成プロキシは、「ブランチ」パラメータを挿入することができます。識別子は同型要求のセット内で一意である必要があります。
Via: SIP/2.0/UDP first.example.com:4000;ttl=16 ;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example) Via: SIP/2.0/UDP adk8
経由：SIP / 2.0 / UDP first.example.com:4000;ttl=16; MADDR = 224.2.0.1;分岐= a7c6a8dlze（実施例）を介し：SIP / 2.0 / UDP adk8
Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by *( ";" via-params ) [ comment ] ) via-params = via-hidden | via-ttl | via-maddr | via-received | via-branch via-hidden = "hidden" via-ttl = "ttl" "=" ttl via-maddr = "maddr" "=" maddr via-received = "received" "=" host via-branch = "branch" "=" token sent-protocol = protocol-name "/" protocol-version "/" transport protocol-name = "SIP" | token protocol-version = token transport = "UDP" | "TCP" | token sent-by = ( host [ ":" port ] ) | ( concealed-host ) concealed-host = token ttl = 1*3DIGIT ; 0 to 255
"："（ ";" 経由のparams）[コメント]送信されたプロトコルが送信-で*（）を経由して-のparams =ヴィア隠さ| 1＃|（ "V" "経由"）を介し= TTL-経由|ビアMADDR |経由して、受信|ビア・ブランチを経由して、隠された= "隠し" 経由-TTL = "TTL" "=" TTL経由-MADDR = "MADDR" "=" MADDRを経由して、受信= "受信" "=" ホストを経由して分岐= "ブランチ" 「=」トークン送らプロトコル=プロトコル名「/」プロトコルバージョン「/」トランスポートプロトコル名=「SIP」|トークン・プロトコル・バージョン=トークン輸送=「UDP」| "TCP" |トークンが送られたバイ=（ホスト[ "：" ポート]）| （隠さホスト）隠蔽ホスト=トークンTTL = 1 * 3DIGIT。 0から255
Figure 11: Syntax of Via header field
図11：のViaヘッダフィールドの構文
The Warning response-header field is used to carry additional information about the status of a response. Warning headers are sent with responses and have the following format:
警告応答ヘッダフィールドは、応答のステータスに関する追加情報を搬送するために使用されます。警告ヘッダーは、応答で送信され、次の形式を持っています：
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
A response MAY carry more than one Warning header.
応答は、複数の警告ヘッダを搬送することができます。
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 cache or user, the Accept-Language field in a request, or the Content-Language field in a response. The default language is i-default [31].
「警告テキストは、」応答を受け取る人間のユーザに理解できる可能性が最も高い自然言語である必要があります。この決定は、応答要求、またはコンテンツ-Languageフィールドで、キャッシュやユーザのロケーションとして使用可能な任意の知識、のAccept-Languageフィールドに基づいて行うことができます。デフォルトの言語は[31] I-デフォルトです。
Any server MAY add Warning headers to a response. Proxy servers MUST place additional Warning headers before any Authorization headers. Within that constraint, Warning headers MUST be added after any existing Warning headers not covered by a signature. A proxy server MUST NOT delete any Warning header field that it received with a response.
任意のサーバが応答に警告ヘッダを追加するかもしれません。プロキシサーバーは、任意の認証ヘッダーの前に追加の警告ヘッダを置かなければなりません。その制約内で、警告ヘッダは、署名によって覆われていない既存の警告ヘッダーの後に追加されなければなりません。プロキシサーバは、応答で受信したWarningヘッダーフィールドを削除してはなりません。
When multiple Warning headers are attached to a response, the user agent SHOULD display as many of them as possible, in the order that they appear in the response. If it is not possible to display all of the warnings, the user agent first displays warnings that appear early in the response.
複数の警告ヘッダーが応答に添付されている場合、ユーザーエージェントは、彼らが反応して表示される順序で、可能な限りそれらの多くが表示されます。それは警告のすべてを表示することができない場合、ユーザーエージェントは、最初の初期応答で表示される警告が表示されます。
The warn-code consists of three digits. A first digit of "3" indicates warnings specific to SIP.
警告コードは3桁の数字で構成されています。 「3」の最初の桁は、SIPに固有の警告を示しています。
This is a list of the currently-defined "warn-code"s, each with a recommended warn-text in English, and a description of its meaning. Note that these warnings describe failures induced by the session description.
これは推奨されると、それぞれが英語であり、その意味の説明テキストを警告し、現在定義されている「警告コード」をSのリストです。これらの警告は、セッション記述によって誘発される障害を記述していることに注意してください。
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.
警告300 329を介しては、379を介して、370はセッション記述で要求された定量的なQoSパラメータに関する警告であり、390、339を介して、330はセッション記述で要求された基本的なネットワークサービスに関連する警告され、セッション記述のキーワードの問題を示すために予約されています399を通じて上記のいずれかのカテゴリに分類されないその他の警告です。
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非互換帯域単位：セッション記述に含まれる1つの以上の帯域幅測定ユニットが理解されませんでした。
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ユニキャストできません：（通常によるファイアウォールの存在のために）、ユーザは、ユニキャスト通信をサポートしていない位置しているサイト。
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, as in the example below, can be defined through IANA.
追加の「警告コード」Sは、以下の例のように、IANAによって定義することができます。
Examples:
例：
Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 301 isi.edu "Incompatible network address type 'E.164'"
警告：301 isi.edu「互換性のないネットワークアドレスタイプ 『E.164』」：307はisi.edu警告「セッションパラメータ 『foo』で理解されていません」
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 Request-URI. See [H14.46] for a definition of the syntax, and section 14 for an overview of usage.
WWW認証応答ヘッダフィールドは401（不正な）応答メッセージに含まれなければなりません。フィールドの値は、Request-URIに適用可能な認証方式（S）とパラメータを示す少なくとも一つのチャレンジから成ります。構文の定義、および使用の概要については、セクション14のために[H14.46]参照。
The content of the "realm" parameter SHOULD be displayed to the user. A user agent SHOULD cache the authorization credentials for a given value of the destination (To header) and "realm" and attempt to re-use these values on the next request for that destination.
「王国」パラメータの内容は、ユーザーに表示されるべきです。ユーザエージェントは、認証先の所定の値に対して（Toヘッダ）の資格情報と、「レルム」をキャッシュし、その宛先に対する次の要求に応じてこれらの値を再使用しようとすべきです。
In addition to the "basic" and "digest" authentication schemes defined in the specifications cited above, SIP defines a new scheme, PGP (RFC 2015, [32]), Section 15. Other schemes, such as S/MIME, are for further study.
「基本」および上記に引用仕様で定義されている認証方式を「ダイジェスト」に加えて、SIPは、S / MIMEなどのセクション15の他の方式は、ためのもので、新方式、PGP（RFC 2015 [32]）定義しますさらなる研究。
7 Status Code Definitions
7つのステータスコードの定義
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. Response codes not defined by HTTP/1.1 have codes x80 upwards to avoid clashes with future HTTP response codes. Also, SIP defines a new class, 6xx. The default behavior for unknown response codes is given for each category of codes.
応答コードは、HTTP / 1.1の応答コードと一致している、と延びています。いないすべてのHTTP / 1.1応答コードは適切であり、唯一の適切なものは、ここに与えられています。その他のHTTP / 1.1応答コードを使用しないでください。 HTTP / 1.1で定義されていないレスポンスコードは、コードが将来のHTTP応答コードとの衝突を避けるために、上向きにX80います。また、SIPは新しいクラス、6xxのを定義します。不明な応答コードのデフォルトの動作は、コードの各カテゴリのために与えられています。
Informational responses indicate that the server or proxy contacted is performing some further action and does not yet have a definitive response. The client SHOULD wait for a further response from the server, and the server SHOULD send such a response without further prompting. A server SHOULD send a 1xx response if it expects to take more than 200 ms to obtain a final response. A server MAY issue zero or more 1xx responses, with no restriction on their ordering or uniqueness. Note that 1xx responses are not transmitted reliably, that is, they do not cause the client to send an ACK. Servers are free to retransmit informational responses and clients can inquire about the current state of call processing by re-sending the request.
情報応答は連絡サーバーまたはプロキシは、さらにいくつかのアクションを実行しているし、まだ決定的な応答を持っていないことを示しています。クライアントは、サーバからの更なる応答を待つ必要があり、サーバは、さらにプロンプトを表示せず、そのような応答を送信すべきです。それが最終的な応答を得るために、200ミリ秒以上を取ることを期待している場合、サーバーはの1xx応答を送るべきです。サーバーは、その順序やユニークさに制限なしで、ゼロ個以上の1xx応答を発行することができます。 1xx応答は確実に伝達されていない、つまり、彼らは、クライアントがACKを送信することはありませんので注意してください。サーバは情報の応答を再送信して自由であり、クライアントが要求を再送信することによって、呼処理の現在の状態を問い合わせることができます。
Some unspecified action is being taken on behalf of this call (e.g., a database is being consulted), but the user has not yet been located.
いくつかの不特定のアクションは、（例えば、データベースが相談されている）、この呼び出しに代わって取られているが、ユーザはまだありますされていません。
The called user agent has located a possible location where the user has registered recently and is trying to alert the user.
ユーザーエージェントは、ユーザーが最近登録した可能性の場所に位置しており、ユーザーに警告しようとしています。
A proxy server MAY use this status code to indicate that the call is being forwarded to a different set of destinations.
プロキシサーバは、コールが宛先の異なるセットに転送されていることを示すために、このステータスコードを使用するかもしれません。
The called party is temporarily unavailable, but the callee 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, e.g., "5 calls queued; expected waiting time is 15 minutes". The server MAY issue several 182 responses to update the caller about the status of the queued call.
被呼者が一時的に利用できないですが、呼び出し先は、コールをキューイングではなく、それを拒否することを決定しました。呼び出し先が利用可能になると、それは適切な最終ステータス応答を返します。フレーズは、コールのステータスについての更なる詳細を与える可能性の理由は、例えば、「5つのコールはキューに入れられ、予想待ち時間は15分です」。サーバーは、キューに入れられたコールのステータスについて発信者を更新するために、いくつかの182応答を発行することができます。
The request was successful and MUST terminate a search.
リクエストが成功したと探索を終えなければなりません。
The request has succeeded. The information returned with the response depends on the method used in the request, for example:
リクエストが成功しました。応答で返された情報は、例えば、要求に使用される方法に依存します。
BYE: The call has been terminated. The message body is empty.
BYE：コールが終了しました。メッセージ本文は空です。
CANCEL: The search has been cancelled. The message body is empty.
CANCEL：検索がキャンセルされました。メッセージ本文は空です。
INVITE: The callee has agreed to participate; the message body indicates the callee's capabilities.
INVITE：呼び出し先が参加することに合意しました。メッセージ本文には、呼び出し先の能力を示しています。
OPTIONS: The callee has agreed to share its capabilities, included in the message body.
OPTIONS：呼び出し先がその機能を共有することに合意した、メッセージ本文に含まれています。
REGISTER: The registration has succeeded. The client treats the message body according to its Content-Type.
登録します。登録が成功しました。クライアントは、そのコンテンツタイプに応じてメッセージ本文を扱います。
3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. They SHOULD terminate an existing search, and MAY cause the initiator to begin a new search if appropriate.
3xx応答は、ユーザーの新しい場所について、またはコールを満たすことができるかもしれない代替サービスについての情報を提供します。彼らは、既存の検索を終了する必要があり、適切であれば、新たな検索を開始するために、イニシエータが発生することがあります。
Any redirection (3xx) response MUST NOT suggest any of the addresses in the Via (Section 6.40) path of the request in the Contact header field. (Addresses match if their host and port number match.)
どれリダイレクション（3xxの）応答は、Contactヘッダーフィールドで要求の経由（セクション6.40）パス内のアドレスのいずれかを示唆してはなりません。 （アドレスはそのホストとポート番号が一致した場合に一致します。）
To avoid forwarding loops, a user agent client or proxy MUST check whether the address returned by a redirect server equals an address tried earlier.
転送ループを回避するために、ユーザエージェントクライアントまたはプロキシはリダイレクトサーバによって返されたアドレスは、アドレスが以前試した等しいかどうかをチェックしなければなりません。
The address in the request resolved to several choices, each with its own specific location, and the user (or user agent) can select a preferred communication end point and redirect its request to that location.
いくつかの選択肢に解決リクエストのアドレスが、それ自身の特定の位置、及びユーザ（またはユーザエージェント）とのそれぞれは、好ましい通信エンドポイントを選択し、その場所にその要求をリダイレクトすることができます。
The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate, if allowed by the Accept request header. The entity format is specified by the media type given in the Content-Type header field. The choices SHOULD also be listed as Contact fields (Section 6.13). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. User agents 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.
応答は、受け入れ要求ヘッダーによって許可されている場合、ユーザーまたはユーザーエージェントは、最も適切なものを選択することができ、そこからリソース特性および位置（単数または複数）のリストを含むエンティティを含むべきです。エンティティフォーマットはContent-Typeヘッダフィールドで指定されたメディアタイプによって指定されます。選択肢はまた、連絡先フィールド（セクション6.13）として表示されます。 HTTPとは異なり、SIP応答は、いくつかの連絡先フィールドまたはContactフィールド内のアドレスのリストを含むかもしれません。ユーザエージェントは、自動リダイレクトのための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.
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 6.13). The caller SHOULD update any local directories, address books and user location caches with this new value and redirect future requests to the address(es) listed.
ユーザーは、もはや要求URI内のアドレスで見つけることができず、要求しているクライアントは、Contactヘッダーフィールド（セクション6.13）によって与えられた新しいアドレスで再試行する必要があります。呼び出し側は、この新しい値を持つ任意のローカルディレクトリ、アドレス帳やユーザーの場所キャッシュを更新し、リストされたアドレス（複数可）に今後の要求をリダイレクトする必要があります。
The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 6.13). The duration of the redirection can be indicated through an Expires (Section 6.20) header. If there is no explicit expiration time, the address is only valid for this call and MUST NOT be cached for future calls.
要求しているクライアントは、Contactヘッダーフィールド（セクション6.13）によって与えられた新しいアドレス（複数可）で要求を再試行する必要があります。 （セクション6.20）Expiresヘッダを介してリダイレクションの持続時間を示すことができます。明示的な有効期限がない場合、アドレスはこの呼び出しに対してのみ有効であり、今後の呼び出しのためにキャッシュされてはなりません。
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 responses MUST only be generated by user agent servers.
要求されたリソースは、Contactフィールドに指定されたプロキシ経由でアクセスする必要があります。 ContactフィールドはプロキシのURIを提供します。受信者は、プロキシを経由してこの単一の要求を繰り返すことが予想されます。 305の応答は、ユーザー・エージェント・サーバによって生成されなければなりません。
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.
呼び出しが成功しませんでしたが、代替サービスが可能です。代替サービスは、応答のメッセージボディに記述されています。そのような体のためのフォーマットは、ここで定義されていない、そして将来の標準化の対象とすることができます。
4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (e.g., adding appropriate authorization). However, the same request to a different server might be successful.
4xx応答は、特定のサーバーからの明確な障害応答です。クライアントは、（適切な権限を追加して、例えば）変更することなく、同じ要求を再試行すべきではありません。しかし、別のサーバーに同じ要求が成功したかもしれません。
The request could not be understood due to malformed syntax.
リクエストの文法が間違っているために理解することができませんでした。
The request requires user authentication.
要求は、ユーザの認証が必要です。
Reserved for future use.
将来の使用のために予約されています。
The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated.
サーバーは要求を理解したが、それを実行することを拒否しています。承認は助けにはなりませんし、要求が繰り返されるべきではありません。
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.
サーバは、ユーザが要求URIで指定されたドメインに存在しないという決定的な情報を持っています。要求URI内のドメインは、要求の受信者が取り扱うドメインのいずれかと一致しない場合、このステータスも返されます。
The method specified in the Request-Line is not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address.
リクエストラインで指定されたメソッドは、Request-URIによって識別されるアドレスは許可されていません。応答は、示されたアドレスのための有効な方法のリストを含む許可ヘッダーフィールドを含まなければなりません。
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
リクエストによって識別されたリソースは、リクエストで送信受け入れるヘッダによれば受け入れられないコンテンツ特性を持つ応答エンティティを生成することができるだけです。
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 6.26) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 6.27). SIP access authentication is explained in section 13.2 and 14.
このコードは401（不正）に類似しているが、クライアントが最初にプロキシで自身を認証しなければならないことを示しています。プロキシは、要求されたリソースのプロキシに適用チャレンジを含むプロキシ認証ヘッダフィールド（セクション6.26）を返さなければなりません。クライアントは、適切なProxy-Authorizationヘッダフィールド（セクション6.27）を用いて要求を繰り返してもよいです。 SIPアクセス認証は、セクション13.2及び14で説明されています。
This status code is used for applications where access to the communication channel (e.g., a telephony gateway) rather than the callee requires authentication.
このステータスコードはむしろ被呼よりも通信チャネル（例えば、電話ゲートウェイ）へのアクセスが認証を必要とする用途に使用されます。
The server could not produce a response, e.g., a user location, within the time indicated in the Expires request-header field. The client MAY repeat the request without modifications at any later time.
サーバは、有効期限リクエストヘッダフィールドで示された時間内に、例えば、ユーザの位置を応答を生成することができませんでした。クライアントは、それ以降の時間に変更することなく、要求を繰り返してもよいです。
The request could not be completed due to a conflict with the current state of the resource. This response is returned if the action parameter in a REGISTER request conflicts with existing registrations.
要求は、リソースの現在の状態との競合に完了することができませんでした。 REGISTERリクエストのactionパラメータは、既存の登録と競合する場合には、この応答が返されます。
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（見つかりません）が代わりに使用する必要があります。
The server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.
サーバーは、Content-Lengthが定義させずに要求を受け入れることを拒否します。それは要求メッセージにメッセージボディの長さを含む有効なContent-Lengthヘッダフィールドを追加する場合、クライアントはリクエストを繰り返す事ができます。
The server is refusing to process a request because the request entity 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.
条件が一時的である場合、サーバはそれが一時的なもので、何時間後にクライアントが再試行してください可能性があることを示すために再試行-Afterヘッダフィールドを含むべきです。
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.
サーバは、サーバが解釈していく所存ですよりも、リクエスト-URIが長くなるため、要求のサービスを拒否しています。
The server is refusing to service the request because the message body of the request is in a format not supported by the requested resource for the requested method. The server SHOULD return a list of acceptable formats using the Accept, Accept-Encoding and Accept-Language header fields.
サーバーは、要求のメッセージボディには要求されたメソッドのために要求されたリソースによってサポートされていない形式であるため、要求のサービスを拒否しています。サーバは、受け入れ承諾エンコードおよびヘッダフィールド言語受け入れ使用可能な形式のリストを返すべきです。
The server did not understand the protocol extension specified in a Require (Section 6.30) header field.
サーバは、要求（セクション6.30）ヘッダフィールドで指定されたプロトコル拡張を理解していませんでした。
The callee's end system was contacted successfully but the callee is currently unavailable (e.g., not logged in or logged in in such a manner as to preclude communication with the callee). The response MAY indicate a better time to call in the Retry-After header. The user could also be available elsewhere (unbeknownst to this host), thus, this response does not terminate any searches. The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be setable by the user agent. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure.
呼び出し先のエンドシステムが正常に接触させたが、呼び出し先が現在使用できません（被呼者との通信を排除するように例えば、ログイン又はようにログインしていません）。応答が再試行-Afterヘッダで電話をかけるのに都合のいい時間を示すことがあります。また、ユーザーはこのように、この応答は、任意の検索を終了していない、（このホストに知られず）他の場所で利用可能である可能性があります。理由句は、呼び出し先が使用できない理由として、より正確な原因を示す必要があります。この値は、ユーザエージェントによって設定可能なあるべきです。ステータス486（ここではBusy）がより正確にコール失敗の特定の理由を示すために使用されるかもしれません。
This status is also returned by a redirect server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user.
このステータスは、要求URIで識別されるユーザーを認識リダイレクトサーバによって返されたが、現在はそのユーザーの有効な転送場所を持っていません。
This status is returned under two conditions: The server received a BYE request that does not match any existing call leg or the server received a CANCEL request that does not match any existing transaction. (A server simply discards an ACK referring to an unknown transaction.)
このステータスは、二つの条件の下で返されます。サーバーは、既存のコールレッグまたは既存のトランザクションと一致しないCANCELリクエストを受信したサーバと一致していませんBYE要求を受けました。 （サーバは、単に、未知のトランザクションを参照するACKを破棄します。）
The server received a request with a Via (Section 6.40) path containing itself.
サーバー自体を含むVia（セクション6.40）パスで依頼を受けました。
The server received a request that contains more Via entries (hops) (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header field.
サーバは、最大転送し（セクション6.23）ヘッダフィールドで許可さよりエントリ（ホップ）（セクション6.40）を介して複数を含む要求を受信しました。
The server received a request with a To (Section 6.37) address or Request-URI that was incomplete. Additional information SHOULD be provided.
サーバは不完全であった（セクション6.37）アドレスまたはリクエストURIのある要求を受信しました。追加情報が提供されるべきです。
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
status response.
The callee address provided in the request was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact headers.
リクエストで提供呼び出し先アドレスがあいまいでした。応答は、Contactヘッダーの可能性明確なアドレスのリストを含むかもしれません。
Revealing alternatives can infringe on privacy concerns 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 if the request address was ambiguous.
代替案を明らかにすることは、ユーザーまたは組織のプライバシーの問題を侵害することができます。ステータス404（見つかりません）で応答するか、要求アドレスがあいまいだった場合に可能な選択肢のリストを抑制するためにサーバーを設定することは可能でなければなりません。
Example response to a request with the URL lee@example.com :
URLのlee@example.comとのリクエストに例応答：
485 Ambiguous SIP/2.0 Contact: Carol Lee <sip:carol.lee@example.com>
485あいまいなSIP / 2.0連絡先：キャロル・リー<SIP：carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com> Contact: Lee M. Foote <sip:lee.foote@example.com>
連絡先：Pingのリー<一口：p.lee@example.com>お問い合わせ：リーM.フット<SIP：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 response.
The callee's end system was contacted successfully but the callee is currently not willing or able to take additional calls. The response MAY indicate a better time to call in the Retry-After header. The user could also be available elsewhere, such as through a voice mail service, thus, this response does not terminate any searches. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call.
呼び出し先のエンドシステムが正常に接触させたが、呼び出し先は、現在、喜んまたは追加の電話を取ることができません。応答が再試行-Afterヘッダで電話をかけるのに都合のいい時間を示すことがあります。また、ユーザーはこのように、この応答は、任意の検索を終了していない、などのボイスメールサービスを介するなど、他の場所で利用可能である可能性があります。クライアントは、他のエンド・システムは、このコールを受け入れることができないことを知っている場合にはステータス600（どこでもBusy）が使用されるべきです。
5xx responses are failure responses given when a server itself has erred. They are not definitive failures, and MUST NOT terminate a search if other possible locations remain untried.
5xx応答は、サーバー自体が誤りを犯した時に与えられた失敗応答です。彼らは決定的な故障ではなく、他の可能な場所が未試行残っている場合は、検索を終了してはなりません。
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.
サーバーは、要求を満たすことを妨げる予期しない状態に遭遇しました。クライアントは、特定のエラー状態を表示し、数秒後に要求を再試行してもよい（MAY）。
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any user.
サーバは要求を満たすために必要な機能をサポートしていません。これは、サーバがリクエストメソッドを認識しないし、すべてのユーザーのためにそれに対応する機能がない適切な対応です。
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 is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client MUST handle the response as it would for a 500 response.
サーバーは、現在サーバーの一時的な過負荷またはメンテナンスのためにリクエストを処理することができません。含意は、これはしばらく待つと緩和される一時的な状態であるということです。既知の場合、遅延の長さは、リトライ後ヘッダに示されてもよいです。何のリトライ後が指定されていない場合、クライアントは、応答それは500応答の場合と同じように処理する必要があります。
Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers MAY wish to simply refuse the connection.
注意：503のステータスコードの存在は、サーバが過負荷になるとき、それを使用しなければならないことを意味するものではありません。一部のサーバーは、単に接続を拒否することもできます。
The server, while acting as a gateway, did not receive a timely response from the server (e.g., a location server) it accessed in attempting to complete the request.
サーバは、ゲートウェイとして動作しながら、それが要求を完了するためにアクセスサーバ（例えば、位置サーバ）からのタイムリーな応答を受信しませんでした。
The server does not support, or refuses to support, the SIP protocol version that was used in the request message. 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 response MAY contain an entity describing why that version is not supported and what other protocols are supported by that server. The format for such an entity is not defined here and may be the subject of future standardization.
サーバがサポートする、または、要求メッセージで使用されたSIPプロトコルのバージョンをサポートすることを拒否していません。サーバは、このエラーメッセージよりも、他のクライアントと同じメジャーバージョンを使用して要求を完了できないか、不本意であることを示しています。応答はそのバージョンがサポートされておらず、他のどのようなプロトコルは、そのサーバによってサポートされている理由を記述したエンティティを含むかもしれません。そのようなエンティティのフォーマットはここで定義されておらず、将来の標準化の対象とすることができます。
6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. All further searches for this user are doomed to failure and pending searches SHOULD be terminated.
6xx応答は、サーバが要求URIで示されている特定のユーザーに関する決定的な情報だけではなく、特定のインスタンスを持っていることを示しています。このユーザーのすべての更なる検索は失敗する運命にされ、保留中の検索が終了されるべきです。
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. 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.
呼び出し先のエンドシステムが正常に接触させたが、呼び出し先がビジー状態であると、この時点で電話に出たくありません。応答が再試行-Afterヘッダで電話をかけるのに都合のいい時間を示すことがあります。呼び出し先が呼び出しを衰退の理由を明らかにすることを希望しない場合は、呼び出し先は、代わりにステータスコード603（下落）を使用しています。このステータス応答は、クライアントが（例えばボイスメールシステムなど）は、他のエンドポイントがリクエストにお答えしていないことを知っている場合にのみ返されます。それ以外の場合は、486（ここでBusy）が返されるべきです。
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.
呼び出し先のマシンが正常に接触させたが、ユーザーが明示的に希望していないか、参加することはできません。応答が再試行-Afterヘッダで電話をかけるのに都合のいい時間を示すことがあります。
The server has authoritative information that the user indicated in the To request field does not exist anywhere. Searching for the user elsewhere will not yield any results.
サーバーは、フィールドを要求するに示されているユーザーはどこにも存在しないという信頼できる情報を持っています。他の場所でユーザーを検索しても、結果が得られません。
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. Reasons are listed in Section 6.41. 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.
606（許容できない）応答は、ユーザが通信したいが、十分に説明セッションをサポートすることができないことを意味します。 606（許容できない）応答を説明セッションをサポートすることができない理由を説明する警告ヘッダフィールドの理由のリストを含むことができます。理由は、セクション6.41に記載されています。その交渉が頻繁に必要とされることはありません期待され、そして新しいユーザーが既存の会議に招待されている場合、交渉はできないことがあります。それは606（許容できない）応答に作用するかどうかを決定するために招待イニシエータ次第です。
8 SIP Message Body
8 SIPメッセージ本文
Requests MAY contain message bodies unless otherwise noted. Within this specification, the BYE request MUST NOT contain a message body. For ACK, INVITE and OPTIONS, the message body is always a session description. The use of message bodies for REGISTER requests is for further study.
特に断りのない限り、要求はメッセージ本体を含むかもしれません。この仕様書の中で、BYE要求は、メッセージ本体を含んではなりません。 ACKは、INVITEおよびオプションについては、メッセージ本体は常にセッション記述です。 REGISTER要求のためのメッセージ本文の利用は、今後の検討課題です。
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. Message bodies for 1xx responses contain advisory information about the progress of the request. 2xx responses to INVITE requests contain session descriptions. In 3xx responses, the message body MAY contain the description of alternative destinations or services, as described in Section 7.3. For responses with status 400 or greater, the message body MAY contain additional, human-readable information about the reasons for failure. It is RECOMMENDED that information in 1xx and 300 and greater responses be of type text/plain or text/html
応答メッセージは、要求メソッドとレスポンスステータスコードは、任意のメッセージ本体の種類及び解釈を決定します。すべての応答が体を含むかもしれません。 1xx応答のメッセージ本文は、要求の進行状況に関する助言情報が含まれています。 INVITEリクエストする2xx応答はセッション記述が含まれています。 7.3節で説明したように3xx応答では、メッセージ本体は、代替地やサービスの説明を含むかもしれません。ステータス400以上との回答については、メッセージ本文には、失敗の理由についての追加、人間が読み取り可能な情報を含むかもしれません。 1XXと300の情報とより大きな応答がタイプtext / plainまたはテキスト/ HTMLであることが推奨されます
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-Typeヘッダフィールドによって与えられなければなりません。本体（圧縮など）の任意の符号化が施された場合、これは、そうでなければコンテンツエンコードを省略しなければならない、コンテンツエンコードヘッダフィールドによって示さなければなりません。該当する場合、メッセージ本文の文字セットは、コンテンツタイプヘッダフィールド値の一部として示されています。
The body length in bytes SHOULD be given by the Content-Length header field. Section 6.15 describes the behavior in detail.
バイト単位の体長は、Content-Lengthヘッダフィールドによって与えられるべきです。 6.15節は、詳細に動作を説明します。
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.)
HTTP / 1.1の転送符号化がSIPのために使用してはいけません「チャンク」。 （注：チャンクエンコーディングはそれぞれ独自のサイズインジケータと、一連のチャンクとして転送するためにメッセージの本文を修正します。）
9 Compact Form
9コンパクトなフォーム
When SIP is carried over UDP with authentication and a complex session description, it may be possible that the size of a request or response is larger than the MTU. To address this problem, a more compact form of SIP is also defined by using abbreviations for the common header fields listed below:
SIPは、認証および複合セッション記述とUDPを介して搬送されるとき、要求または応答のサイズがMTUよりも大きいことが可能であってもよいです。この問題に対処するために、SIPのよりコンパクトな形態も下記の共通ヘッダフィールドの略語を使用して定義されます。
short field name long field name note c Content-Type e Content-Encoding f From i Call-ID m Contact from "moved" l Content-Length s Subject t To v Via
短いフィールド名ロングフィールド名注CのContent-Typeの電子コンテンツ・エンコーディングFからIコールIDのm個の接点を介してVまでをtリットルのContent-Lengthの件名を「移動」から
Thus, the message in section 16.2 could also be written:
このように、セクション16.2でメッセージを書き込むこともできます。
INVITE sip:schooler@vlsi.caltech.edu SIP/2.0 v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16 v:SIP/2.0/UDP 128.16.64.19 f:sip:mjh@isi.edu t:sip:schooler@cs.caltech.edu i:62729-27@128.16.64.19 c:application/sdp CSeq: 4711 INVITE l:187
SIPのINVITE：schooler@vlsi.caltech.eduのSIP / 2.0 V：SIP / 2.0 / UDP 131.215.131.131; MADDR = 239.128.16.254; TTL = 16 V：SIP / 2.0 / UDP 128.16.64.19 F：SIP：MJH ISI @ .eduさらにさt：SIP：schooler@cs.caltech.edu I：62729-27@128.16.64.19 C：アプリケーション/ SDPのCSeq：4711リットルのINVITE：187
v=0 o=user1 53655765 2353687637 IN IP4 128.3.4.5 s=Mbone Audio i=Discussion of Mbone Engineering Issues e=mbone@somewhere.com c=IN IP4 224.2.0.1/127 t=0 0 m=audio 3456 RTP/AVP 0
IP4 128.3.4.5 S = MBONEオーディオ、V IN = 0 0 = USER1 53655765 2353687637 I = MBONEエンジニアリングの問題についての議論e=mbone@somewhere.com C = IP4 224.2.0.1/127トン= 0 0メートル=オーディオ3456 RTP IN / AVP 0
Clients MAY mix short field names and long field names within the same request. Servers MUST accept both short and long field names for requests. Proxies MAY change header fields between their long and short forms, but this MUST NOT be done to fields following an Authorization header.
クライアントは同じリクエスト内の短いフィールド名と長いフィールド名を混在してもよい（MAY）。サーバーは、要求のための短期および長期の両方のフィールド名を受け入れなければなりません。プロキシは、彼らの長い形式と短い形式の間でヘッダフィールドを変更することがありますが、Authorizationヘッダー、次のフィールドにしてはいけません。
10 Behavior of SIP Clients and Servers
SIPクライアントとサーバーの10挙動
SIP is defined so it can use either UDP (unicast or multicast) or TCP as a transport protocol; it provides its own reliability mechanism.
それはトランスポートプロトコルとしてUDP（ユニキャストまたはマルチキャスト）またはTCPのいずれかを使用できるように、SIPが定義されています。それは、独自の信頼性のメカニズムを提供します。
Servers discard isomorphic requests, but first retransmit the appropriate response. (SIP requests are said to be idempotent , i.e., receiving more than one copy of a request does not change the server state.)
サーバは同型の要求を破棄しますが、最初に適切な応答を再送信します。 （SIPリクエストは、冪等すると言われている、すなわち、サーバの状態を変更しない要求の複数のコピーを受信します。）
After receiving a CANCEL request from an upstream client, a stateful proxy server MAY send a CANCEL on all branches where it has not yet received a final response.
上流のクライアントからのキャンセル要求を受信した後、ステートフルプロキシサーバは、それはまだ最終的な応答を受信していないすべての枝にCANCELを送信することができます。
When a user agent receives a request, it checks the Call-ID against those of in-progress calls. If the Call-ID was found, it compares the tag value of To with the user's tag and rejects the request if the two do not match. If the From header, including any tag value, matches the value for an existing call leg, the server compares the CSeq header field value. If less than or equal to the current sequence number, the request is a retransmission. Otherwise, it is a new request. If the From header does not match an existing call leg, a new call leg is created.
ユーザエージェントは、要求を受け取ると、それは進行中のコールのそれに対するコールIDをチェックします。コールIDが見つかった場合、それはユーザーのタグでのタグ値を比較し、両者が一致しない場合は、要求を拒否します。任意のタグ値を含むヘッダ、から、既存のコールレッグの値と一致した場合、サーバーはCSeqヘッダーフィールド値を比較します。以下現在のシーケンス番号に等しい場合、要求は再送信です。それ以外の場合は、新しい要求です。 Fromヘッダー既存のコールレッグと一致しない場合、新しいコールレッグが作成されます。
If the Call-ID was not found, a new call leg is created, with entries for the To, From and Call-ID headers. In this case, the To header field should not have contained a tag. The server returns a response containing the same To value, but with a unique tag added. The tag MAY be omitted if the request contained only one Via header field.
コールIDが見つからなかった場合は、新しいコールレッグがへのエントリで、作成されてから、およびCall-IDヘッダを。この場合には、Toヘッダーフィールドは、タグを含有しているべきではありません。サーバは、値にそれを含む応答を返すが、一意のタグを付加しました。要求は一つだけのViaヘッダーフィールドが含まれている場合、タグを省略することができます。
A server MAY issue one or more provisional responses at any time before sending a final response. If a stateful proxy, user agent server, redirect server or registrar cannot respond to a request with a final response within 200 ms, it SHOULD issue a provisional (1xx) response as soon as possible. Stateless proxies MUST NOT issue provisional responses on their own.
サーバーは、最終的な応答を送信する前にいつでも、一つ以上の暫定応答を発行することができます。ステートフルプロキシ場合は、ユーザエージェントサーバは、サーバにリダイレクトするか、レジストラが200ミリ秒内の最終的な応答で要求に応答することができない、それはできるだけ早く暫定（1xxの）応答を発行する必要があります。ステートレスプロキシは、独自の暫定応答を発行してはいけません。
Responses are mapped to requests by the matching To, From, Call-ID, CSeq headers and the branch parameter of the first Via header. Responses terminate request retransmissions even if they have Via headers that cause them to be delivered to an upstream client.
応答は、コールIDを、のCSeqヘッダと第Viaヘッダの分岐パラメータから、との整合により要求にマッピングされます。彼らは彼らが上流のクライアントに配信することが原因のViaヘッダを持っている場合でも、応答は要求の再送信を終了します。
A stateful proxy may receive a response that it does not have state for, that is, where it has no a record of an associated request. If the Via header field indicates that the upstream server used TCP, the proxy actively opens a TCP connection to that address. Thus, proxies have to be prepared to receive responses on the incoming side of passive TCP connections, even though most responses will arrive on the incoming side of an active connection. (An active connection is a TCP connection initiated by the proxy, a passive connection is one accepted by the proxy, but initiated by another entity.)
ステートフルプロキシは、それが関連する要求のないレコードを有する場合、すなわち、の状態を有していない旨の応答を受信することができます。 Viaヘッダーフィールドは、上流のサーバがTCPを使用することを示している場合、プロキシは積極的にそのアドレスへのTCP接続を開きます。したがって、プロキシはほとんど応答がアクティブな接続の入射側に到着するにもかかわらず、パッシブTCP接続の着信側の応答を受信するために準備されなければなりません。 （アクティブな接続が、プロキシによって開始されたTCP接続である、パッシブ接続は、プロキシによって受け入れられるものであるが、別のエンティティによって開始されます。）
100 responses SHOULD NOT be forwarded, other 1xx responses MAY be forwarded, possibly after the server eliminates responses with status codes that had already been sent earlier. 2xx responses are forwarded according to the Via header. Once a stateful proxy has received a 2xx response, it MUST NOT forward non-2xx final responses. Responses with status 300 and higher are retransmitted by each stateful proxy until the next upstream proxy sends an ACK (see below for timing details) or CANCEL.
100個の応答が転送されるべきではない、他の1xx応答は、サーバがすでに以前に送られたステータスコードで応答がなくなり、おそらく後、転送されてもよいです。 2xx応答は、Viaヘッダに応じて転送されます。ステートフルプロキシは2xx応答を受信したら、それは非2xxの最終応答を転送してはなりません。次の上流プロキシはACKを送信する（タイミングの詳細については以下を参照）、またはキャンセルするまで状態300以降で応答が各ステートフルプロキシによって再送信されます。
A stateful proxy SHOULD maintain state for at least 32 seconds after the receipt of the first definitive non-200 response, in order to handle retransmissions of the response.
ステートフルプロキシは、応答の再送信を処理するために、最初の決定的な非200応答の受信後、少なくとも32秒間状態を維持する必要があります。
The 32 second window is given by the maximum retransmission
duration of 200-class responses using the default timers,
in case the ACK is lost somewhere on the way to the called
user agent or the next stateful proxy.
Responses are returned to the address listed in the Via header field (Section 6.40), not the source address of the request.
応答は、Viaヘッダーフィールドにリストされたアドレス（セクション6.40）、ない要求の送信元アドレスに戻されます。
Recall that responses are not generated by the next-hop
stateless server, but generated by either a proxy server or
the user agent server. Thus, the stateless proxy can only
use the Via header field to forward the response.
Requests MAY be multicast; multicast requests likely feature a host-independent Request-URI. This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. This MAY be done with either TTL or administrative scopes[25], depending on what is implemented in the network.
要求は、マルチキャストなる場合があります。マルチキャスト要求は、おそらくホストに依存しないのRequest-URIを備えています。この要求は、それが行政システムの境界を越えて転送されていないことを確認するためにスコープされるべきである（SHOULD）。これは、ネットワークに実装されているものに応じて、[25] TTLまたは管理スコープのいずれかで行うことができます。
A client receiving a multicast query does not have to check whether the host part of the Request-URI matches its own host or domain name. If the request was received via multicast, the response is also returned via multicast. Responses to multicast requests are multicast with the same TTL as the request, where the TTL is derived from the ttl parameter in the Via header (Section 6.40).
マルチキャストクエリーを受信するクライアントは、Request-URIのホスト部分は、独自のホスト名またはドメイン名に一致するかどうかを確認する必要はありません。要求は、マルチキャストを介して受信された場合、応答は、マルチキャストを介して返されます。マルチキャスト要求に対する応答はTTLをViaヘッダ（セクション6.40）におけるTTLパラメータから導出される要求と同じTTLを持つマルチキャストされます。
To avoid response implosion, servers MUST NOT answer multicast requests with a status code other than 2xx or 6xx. The server delays its response by a random interval uniformly distributed between zero and one second. Servers MAY suppress responses if they hear a lower-numbered or 6xx response from another group member prior to sending. Servers do not respond to CANCEL requests received via multicast to avoid request implosion. A proxy or UAC SHOULD send a CANCEL on receiving the first 2xx or 6xx response to a multicast request.
応答爆縮を避けるために、サーバは、2xxのかの6xx以外のステータスコードでマルチキャスト要求に答えてはなりません。サーバは、一様に0と1秒の間に分布ランダムな間隔によって、その応答を遅らせます。彼らは、送信する前に、別のグループのメンバーから低い番号または6xxの応答を聞いている場合、サーバーが応答を抑制することができます。サーバーは、要求爆縮を避けるために、マルチキャストを介して受信されたリクエストをキャンセルする応答しません。プロキシまたはUACは、マルチキャスト要求への最初の2xx又は6xxの応答を受信する送信キャンセルすべきです。
Server response suppression is a MAY since it requires a
server to violate some basic message processing rules. Lets
say A sends a multicast request, and it is received by B,C,
and D. B sends a 200 response. The topmost Via field in the
response will contain the address of A. C will also receive
this response, and could use it to suppress its own
response. However, C would normally not examine this
response, as the topmost Via is not its own. Normally, a
response received with an incorrect topmost Via MUST be
dropped, but not in this case. To distinguish this packet
from a misrouted or multicast looped packet is fairly
complex, and for this reason the procedure is a MAY. The
CANCEL, instead, provides a simpler and more standard way
to perform response suppression. It is for this reason that
the use of CANCEL here is a SHOULD
A single TCP connection can serve one or more SIP transactions. A transaction contains zero or more provisional responses followed by one or more final responses. (Typically, transactions contain exactly one final response, but there are exceptional circumstances, where, for example, multiple 200 responses can be generated.)
単一のTCP接続は、一つ以上のSIPトランザクションを果たすことができます。トランザクションは、1つの以上の最終応答に続くゼロ個以上の暫定応答が含まれています。 （典型的には、トランザクションは、1つの最終的な応答を含むが、例えば、複数の200の応答を生成することができ、例外的な状況があります。）
The client SHOULD keep the connection open at least until the first final response arrives. If the client closes or resets the TCP connection prior to receiving the first final response, the server treats this action as equivalent to a CANCEL request.
最初の最終応答が到着するまで、少なくともクライアントがオープン接続を維持する必要があります。クライアントは、CANCELリクエストと同等にこのアクションを閉じるかリセット最初の最終的な応答を受信する前にTCPコネクションを、サーバ扱います。
This behavior makes it less likely that malfunctioning
clients cause a proxy server to keep connection state
indefinitely.
The server SHOULD NOT close the TCP connection until it has sent its final response, at which point it MAY close the TCP connection if it wishes to. However, normally it is the client's responsibility to close the connection.
それがしたい場合には、TCP接続を閉じるかもしれない、その時点でその最終的な応答を送信したまで、サーバーは、TCPコネクションをクローズすべきではありません。しかし、通常、接続を閉じるには、クライアントの責任です。
If the server leaves the connection open, and if the client so desires it MAY re-use the connection for further SIP requests or for requests from the same family of protocols (such as HTTP or stream control commands).
サーバが接続を開いたままにし、クライアントがそう望む場合には、さらにSIP要求のか（例えばHTTPまたはストリーム制御コマンドなど）のプロトコルの同じ家族からの要求のための接続を再使用する可能性がある場合。
If a server needs to return a response to a client and no longer has a connection open to that client, it MAY open a connection to the address listed in the Via header. Thus, a proxy or user agent MUST be prepared to receive both requests and responses on a "passive" connection.
サーバがクライアントに応答を返す必要があり、もはやそのクライアントへの接続を開いている場合、それはViaヘッダに記載されているアドレスへの接続を開くことができます。このように、プロキシまたはユーザエージェントは、「受動的」接続の両方の要求と応答を受け取るために準備しなければなりません。
A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or REGISTER request with an exponential backoff, starting at a T1 second interval, doubling the interval for each packet, and capping off at a T2 second interval. This means that after the first packet is sent, the second is sent T1 seconds later, the next 2*T1 seconds after that, the next 4*T1 seconds after that, and so on, until the interval hits T2. Subsequent retransmissions are spaced by T2 seconds. If the client receives a provisional response, it continues to retransmit the request, but with an interval of T2 seconds. Retransmissions cease when the client has sent a total of eleven packets, or receives a definitive response. Default values for T1 and T2 are 500 ms and 4 s, respectively. Clients MAY use larger values, but SHOULD NOT use smaller ones. Servers retransmit the response upon receipt of a request retransmission. After the server sends a final response, it cannot be sure the client has received the response, and thus SHOULD cache the results for at least 10*T2 seconds to avoid having to, for example, contact the user or location server again upon receiving a request retransmission.
UDPを使用してSIPクライアントは、BYEを再送CANCEL、OPTIONS、または指数バックオフを用いて要求を登録し、T1秒間隔で開始し、各パケットの間隔を倍加し、T2秒間隔で離れキャッピングすべきです。間隔がT2に達するまでこれは、ように、その後、次の4 * T1秒、その後、次の2 * T1秒、最初のパケットが送信された後、第二は、T1秒後送信されることを意味します。その後の再送信は、T2秒だけ離間されています。クライアントが暫定応答を受信した場合、その要求を再送信し続けますが、T2秒の間隔で。クライアントが11パケットの合計を送った、または決定的な応答を受信した場合に再送を止めます。 T1とT2のデフォルト値は、それぞれ500ミリ秒および4秒です。クライアントは、より大きな値を使用することができるが、小さなものを使用しないでください。サーバーは、要求の再送信を受信すると応答を再送信します。サーバーが最終応答を送信した後、それを受信すると、再び、例えば、ユーザまたはロケーションサーバに連絡することを避けるために、少なくとも10 * T2秒の結果をキャッシュするため、クライアントが応答を受信したことを確認して、することはできませんリクエスト再送。
Use of the exponential backoff is for congestion control
purposes. However, the back-off must cap off, since request
retransmissions are used to trigger response
retransmissions at the server. Without a cap, the loss of a
single response could significantly increase transaction
latencies.
The value of the initial retransmission timer is smaller than that that for TCP since it is expected that network paths suitable for interactive communications have round-trip times smaller than 500 ms. For congestion control purposes, the retransmission count has to be bounded. Given that most transactions are expected to consist of one request and a few responses, round-trip time estimation is not likely to be very useful. If RTT estimation is desired to more quickly discover a missing final response, each request retransmission needs to be labeled with its own Timestamp (Section 6.36), returned in the response. The server caches the result until it can be sure that the client will not retransmit the same request again.
初期再送タイマの値は、インタラクティブ通信に適したネットワークパスは500ミリ秒より小さい往復時間を有することが予想されるので、TCPのそれよりも小さいです。輻輳制御の目的のために、再送回数が制限される必要があります。ほとんどのトランザクションは、1つの要求といくつかの応答から構成することが期待されていることを考えると、ラウンドトリップ時間の推定は非常に有用である可能性が高いではありません。 RTT推定をより迅速に欠落している最終的な応答を発見することが望まれる場合は、各要求の再送信は、自身のタイムスタンプ（セクション6.36）で標識される必要があり、応答で返されます。サーバは、クライアントが再び同じ要求を再送信していないことを確認することができますまで、結果をキャッシュします。
Each server in a proxy chain generates its own final response to a CANCEL request. The server responds immediately upon receipt of the CANCEL request rather than waiting until it has received final responses from the CANCEL requests it generates.
プロキシチェーン内の各サーバは、CANCELリクエストへの独自の最終的な応答を生成します。サーバーはCANCELリクエストではなく、それが発生したCANCEL要求から、最終的な応答を受信するまで待機しているの受信時に即座に応答します。
BYE and OPTIONS final responses are generated by redirect and user agent servers; REGISTER final responses are generated by registrars. Note that in contrast to the reliability mechanism described in Section 10.5, responses to these requests are not retransmitted periodically and not acknowledged via ACK.
BYEとOPTIONSの最終応答をリダイレクトし、ユーザエージェントサーバによって生成されます。 REGISTER最終応答は、レジストラによって生成されます。 10.5節で説明した信頼性のメカニズムとは対照的に、これらの要求に対する応答が再送され、定期的にではなくACKを経て認めていないことに注意してください。
Clients using TCP do not need to retransmit requests.
TCPを使用しているクライアントは、要求を再送信する必要はありません。
Special considerations apply for the INVITE method.
特別な考慮事項は、INVITEメソッドに適用されます。
1. After receiving an invitation, considerable time can elapse
before the server can determine the outcome. For example,
if the called party is "rung" or extensive searches are
performed, delays between the request and a definitive
response can reach several tens of seconds. If either
caller or callee are automated servers not directly
controlled by a human being, a call attempt could be
unbounded in time.
2. If a telephony user interface is modeled or if we need to interface to the PSTN, the caller's user interface will provide "ringback", a signal that the callee is being alerted. (The status response 180 (Ringing) MAY be used to initiate ringback.) Once the callee picks up, the caller needs to know so that it can enable the voice path and stop ringback. The callee's response to the invitation could get lost. Unless the response is transmitted reliably, the caller will continue to hear ringback while the callee assumes that the call exists.
2.テレフォニーユーザインターフェイスがモデル化されているか、我々はPSTNにインタフェースする必要がある場合、呼び出し側のユーザーインターフェースは「呼出」、呼び出し先が警告されているという信号を提供するかどうか。被呼者がピックアップしたら（ステータス応答180（リンギング）リングバックを開始するために使用されるかもしれません。）、発信者は、音声パスを有効にして、リングバックを停止することができるように知る必要があります。招待状に呼び出し先の応答が失われる可能性があります。応答は確実に伝達されない限り、呼び出し側は、呼び出し先が呼び出しが存在していることを前提としながら、リングバックが聞こえてまいります。
3. The client has to be able to terminate an on-going request, e.g., because it is no longer willing to wait for the connection or search to succeed. The server will have to wait several retransmission intervals to interpret the lack of request retransmissions as the end of a call. If the call succeeds shortly after the caller has given up, the callee will "pick up the phone" and not be "connected".
3.クライアントは、もはや接続を待つか、成功するために検索していく所存ですので、上の継続など、リクエストを終了することはできませんする必要があります。サーバーは、コールの終了などの要求の再送信の欠如を解釈するために、いくつかの再送信間隔を待機する必要があります。コールは、発信者があきらめた後すぐに成功すると、呼び出し先は、「接続」され、「携帯電話を拾う」としません。
For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an interval that starts at T1 seconds, and doubles after each packet transmission. The client ceases retransmissions if it receives a provisional or definitive response, or once it has sent a total of 7 request packets.
UDPの場合は、SIPクライアントは、SIPは、T1秒で始まり、各パケットの送信後に倍増する間隔でINVITEリクエストを再送信すべきです。それは暫定的または決定的な応答を受信した場合、クライアントは、再送信を停止し、またはそれは、7つの要求パケットの合計を送った後。
A server which transmits a provisional response should retransmit it upon reception of a duplicate request. A server which transmits a final response should retransmit it with an interval that starts at T1 seconds, and doubles for each subsequent packet. Response retransmissions cease when any one of the following occurs:
暫定応答を送信するサーバは、重複要求の受信時にそれを再送信すべきです。最終的な応答を送信するサーバは、T1秒で始まり、各後続パケットに対して倍の間隔でそれを再送信すべきです。以下のいずれかが発生したときに応答再送は停止します：
3. a CANCEL request for the same call leg is received and the final response status was equal or greater to 300;
3. CANCEL同じコールレッグのための要求が受信され、最終的な応答ステータスは300に等しいまたはそれ以上であったれます。
Only the user agent client generates an ACK for 2xx final responses, If the response contained a Contact header field, the ACK MAY be sent to the address listed in that Contact header field. If the response did not contain a Contact header, the client uses the same To header field and Request-URI as for the INVITE request and sends the ACK to the same destination as the original INVITE request. ACKs for final responses other than 2xx are sent to the same server that the original request was sent to, using the same Request-URI as the original request. Note, however, that the To header field in the ACK is copied from the response being acknowledged, not the request, and thus MAY additionally contain the tag parameter. Also note than unlike 2xx final responses, a proxy generates an ACK for non-2xx final responses.
応答はContactヘッダーフィールドが含まれていた場合のみ、ユーザー・エージェント・クライアントは、2xxの最終応答に対するACKを生成し、ACKは、そのContactヘッダーフィールドにリストされたアドレスに送ってもよいです。応答はContactヘッダーが含まれていなかった場合、クライアントは、INVITEリクエストのため、フィールドとRequest-URI Toヘッダー同じを使用し、オリジナルのINVITE要求と同じ宛先にACKを送信します。 2XX以外の最終的な応答のためのACKは、元の要求が元の要求と同様のRequest-URIを使用して、に送られた同じサーバに送信されます。さらに、タグ・パラメータを含むかもしれ従ってACKでToヘッダーフィールドがない要求を承認されて応答からコピーされていること、しかし、注意、および。また、2xxの最終回答とは異なり、プロキシが非2xxの最終応答に対するACKを生成よりも、注意してください。
The ACK request MUST NOT be acknowledged to prevent a response-ACK feedback loop. Fig. 12 and 13 show the client and server state diagram for invitations.
ACK要求は応答ACKのフィードバックループを防ぐために認めてはなりません。図12および13は、招待状のため、クライアントとサーバーの状態図を示しています。
The mechanism in Sec. 10.4 would not work well for INVITE
because of the long delays between INVITE and a final
response. If the 200 response were to get lost, the callee
would believe the call to exist, but the voice path would
+===========+
* *
...........>* Initial *<;;;;;;;;;;
: 7 INVITE * * ;
: sent +===========+ ;
: | ;
: | - ;
: | INVITE ;
: | ;
: v ;
: ************* ;
: T1*2^n <--* * ;
: INVITE -->* Calling *--------+ ;
: * * | ;
: ************* | ;
: : | | ;
:.............: | 1xx xxx | ;
| - ACK | ;
| | ;
v | ;
************* | ;
* * | ;
* Ringing *<->1xx | ;
* * | ;
************* | ;
| | ;
|<-------------+ ;
| ;
v ;
************* ;
xxx <--* * ;
ACK -->* Completed * ;
* * ;
************* ;
; 32s (for proxy);
;;;;;;;;;;;;;;;;;;
event (xxx=status) message
イベント（XXX =ステータス）メッセージ
Figure 12: State transition diagram of client for INVITE method
図12：INVITEメソッドのクライアントの状態遷移図
7 pkts sent +===============+
+-------------->* *
| * Initial *<...............
|;;;;;;;;;;;;;;>* * :
|; +===============+ :
|; CANCEL ! :
|; 200 ! INVITE :
|; ! 1xx :
|; ! :
|; v :
|; ***************** BYE :
|; INVITE -->* * 200 :
|; 1xx <--* Call proceed. *..............>:
|; * * :
|;;;;;;;;;;;;;;;***************** :
|; ! ! :
|: ! ! :
|; failure ! ! picks up :
|; >= 300 ! ! 200 :
|; +-------+ +-------+ :
|; v v :
|; *********** *********** :
|;INVITE<* *<T1*2^n->* *>INVITE :
|;status>* failure *>status<-* success *<status :
|; * * * * :
|;;;;;;;;*********** *********** :
| ! : | | ! : :
| ! : | | ! : :
+-------------!-:-+------------+ ! : :
! :.................!..:.........>:
! ! BYE :
+---------+---------+ 200 :
event ! ACK :
message sent v :
***************** :
V---* * :
ACK * Confirmed * :
|-->* * :
***************** .
:......................>:
Figure 13: State transition diagram of server for INVITE method
図13：INVITEメソッドのためのサーバの状態遷移図
be dead since the caller does not know that the callee has
picked up. Thus, the INVITE retransmission interval would
have to be on the order of a second or two to limit the
duration of this state confusion. Retransmitting the
response with an exponential back-off helps ensure that the
response is received, without placing an undue burden on
the network.
A user agent using TCP MUST NOT retransmit requests, but uses the same algorithm as for UDP (Section 10.5.1) to retransmit responses until it receives an ACK.
TCPを使用して、ユーザーエージェントは、要求を再送信が、それはACKを受信するまでの応答を再送信するためにUDP（第10.5.1項）と同じアルゴリズムを使用してはなりません。
It is necessary to retransmit 2xx responses as their
reliability is assured end-to-end only. If the chain of
proxies has a UDP link in the middle, it could lose the
response, with no possibility of recovery. For simplicity,
we also retransmit non-2xx responses, although that is not
strictly necessary.
The ACK request does not generate responses. It is only generated when a response to an INVITE request arrives (see Section 10.5). This behavior is independent of the transport protocol. Note that the ACK request MAY take a different path than the original INVITE request, and MAY even cause a new TCP connection to be opened in order to send it.
ACK要求は応答を生成しません。それが唯一のINVITE要求に対する応答が到着したときに生成される（項10.5を参照してください）。この動作は、トランスポートプロトコルとは無関係です。 ACK要求は、元のINVITE要求とは異なるパスをとることができ、さらにはそれを送信するためにオープンする新しいTCP接続を引き起こすかもしれないことに注意してください。
Handling of ICMP messages in the case of UDP messages is straightforward. For requests, a host, network, port, or protocol unreachable error SHOULD be treated as if a 400-class response was received. For responses, these errors SHOULD cause the server to cease retransmitting the response.
UDPメッセージの場合、ICMPメッセージの取り扱いが簡単です。要求の場合、ホスト、ネットワーク、ポート、またはプロトコル到達不能エラーは、400クラス応答が受信されたかのように扱われるべきです。応答では、これらのエラーは、サーバーが応答を再送信を中止するようになります。
Source quench ICMP messages SHOULD be ignored. TTL exceeded errors SHOULD be ignored. Parameter problem errors SHOULD be treated as if a 400-class response was received.
ソースクエンチICMPメッセージは無視されるべきです。 TTLは、エラーは無視されるべきである超えました。パラメータ問題エラーは400クラス応答が受信されたかのように扱われるべきです。
11 Behavior of SIP User Agents
SIPユーザエージェントの挙動11
This section describes the rules for user agent client and servers for generating and processing requests and responses.
このセクションでは、要求と応答を生成し、処理するためのユーザー・エージェント・クライアントとサーバのルールを説明しています。
When a user agent client desires to initiate a call, it formulates an INVITE request. The To field in the request contains the address of the callee. The Request-URI contains the same address. The From field contains the address of the caller. If the From address can appear in requests generated by other user agent clients for the same call, the caller MUST insert the tag parameter in the From field. A UAC MAY optionally add a Contact header containing an address where it would like to be contacted for transactions from the callee back to the caller.
ユーザエージェントクライアントがコールを開始することを希望する場合は、INVITE要求を定式化します。リクエストのフィールドに呼び出し先のアドレスが含まれています。 Request-URIが同じアドレスが含まれています。 Fromフィールド、発信者のアドレスが含まれています。アドレスから同じ呼び出しのために他のユーザエージェントクライアントによって生成されたリクエストに表示されることができる場合、呼び出し側は、Fromフィールドにtagパラメータを挿入しなければなりません。 UACは、必要に応じて、それが呼び出し元に呼び出し先からトランザクションに接触させることを希望アドレスを含むContactヘッダを加えるかもしれ。
When the initial INVITE request is received at the callee, the callee can accept, redirect, or reject the call. In all of these cases, it formulates a response. The response MUST copy the To, From, Call-ID, CSeq and Via fields from the request. Additionally, the responding UAS MUST add the tag parameter to the To field in the response if the request contained more than one Via header field. Since a request from a UAC may fork and arrive at multiple hosts, the tag parameter serves to distinguish, at the UAC, multiple responses from different UAS's. The UAS MAY add a Contact header field in the response. It contains an address where the callee would like to be contacted for subsequent transactions, including the ACK for the current INVITE. The UAS stores the values of the To and From field, including any tags. These become the local and remote addresses of the call leg, respectively.
最初のINVITE要求が呼び出し先で受信されると、呼び出し先は、受け入れるリダイレクト、またはコールを拒否することができます。これらすべての場合には、それが応答を定式化します。応答が要求からに、から、コールID、のCSeqおよびVIAフィールドをコピーする必要があります。また、応答UASはリクエストがViaヘッダーフィールドつ以上が含まれている場合、応答のフィールドににタグパラメータを追加する必要があります。 UACからの要求がフォークと、複数のホストに到達する可能性があるため、タグのパラメータは、UACで、区別するために異なるUAS年代から複数の応答を提供しています。 UASは応答してContactヘッダーフィールドを追加するかもしれません。これは、呼び出し先がINVITEを現在のためのACKを含め、その後のトランザクションのために連絡することを希望アドレスが含まれています。 UASは、任意のタグを含むのとフィールドの値が格納されます。これらはそれぞれ、コールレッグのローカルとリモートのアドレスになります。
Multiple 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 call leg. The caller MAY choose to acknowledge or terminate the call with each responding UAS. To acknowledge, it sends an ACK request, and to terminate it sends a BYE request. The To header field in the ACK or BYE MUST be the same as the To field in the 200 response, including any tag. The From header field MUST be the same as the From header field in the 200 (OK) response, including any tag. The Request-URI of the ACK or BYE request MAY be set to whatever address was found in the Contact header field in the 200 (OK) response, if present. Alternately, a UAC may copy the address from the To header field into the Request-URI. The UAC also notes the value of the To and From header fields in each response. For each call leg, the To header field becomes the remote address, and the From header field becomes the local address.
複数の応答が原因フォーキングプロキシに、単一のINVITE要求のためにUACに到着することができます。各応答はToヘッダーフィールドに「タグ」パラメータによって区別され、それぞれが別個のコールレッグを表しています。呼び出し側が認めるか、各応答UASとの通話を終了することを選択するかもしれません。それはACK要求を送信し、承認し、それがBYE要求を送信終了します。 ACKまたはBYEフィールドをヘッダに任意のタグを含む200応答、のフィールドに同じでなければなりません。ヘッダ・フィールドから任意のタグを含む200（OK）応答のヘッダフィールドと同じでなければなりません。 ACKまたはBYE要求のリクエストURIが存在する場合、200（OK）応答のContactヘッダフィールドに発見されたどのアドレスに設定されるかもしれません。交互に、UACは、Request-URIにヘッダーフィールドからアドレスをコピーしてもよいです。 UACは、各応答して、からヘッダフィールドの値を指摘しています。各コールレッグの場合は、Toヘッダーフィールドは、リモートアドレスになり、Fromヘッダーフィールドは、ローカルアドレスになります。
Once the call has been established, either the caller or callee MAY generate INVITE or BYE requests to change or terminate the call. Regardless of whether the caller or callee is generating the new request, the header fields in the request are set as follows. For the desired call leg, the To header field is set to the remote address, and the From header field is set to the local address (both including any tags). The Contact header field MAY be different than the Contact header field sent in a previous response or request. The Request-URI MAY be set to the value of the Contact header field received in a previous request or response from the remote party, or to the value of the remote address.
コールが確立されると、呼び出し元または呼び出し先のどちらかは、INVITE生成することやBYE要求は、変更したり、通話を終了します。次のように関係なく、発呼者又は被呼者が新しい要求を生成しているかどうか、要求のヘッダフィールドが設定されています。所望のコールレッグのために、Toヘッダフィールドは、リモートアドレスに設定され、Fromヘッダフィールド（両方とも任意のタグを含む）をローカルアドレスに設定されています。 Contactヘッダーフィールドは、以前の応答または要求で送信されたContactヘッダーフィールドと異なっていてもよいです。 Request-URIが遠隔パーティから、又はリモートアドレスの値に前の要求または応答で受信したContactヘッダーフィールドの値に設定することができます。
When a request is received subsequently, the following checks are made:
要求が続いて受信されると、以下の検査が行われます。
1. If the Call-ID is new, the request is for a new call,
regardless of the values of the To and From header fields.
2. If the Call-ID exists, the request is for an existing call. If the To, From, Call-ID, and CSeq values exactly match (including tags) those of any requests received previously, the request is a retransmission.
2.コールIDが存在する場合、要求は既存のコールのためです。 Toは、からは、コールIDは、とのCSeq値が正確に（タグを含む）と一致した場合はすべての要求のものは以前に受信し、要求が再送信です。
3. If there was no match to the previous step, the To and From fields are compared against existing call leg local and remote addresses. If there is a match, and the CSeq in the request is higher than the last CSeq received on that leg, the request is a new transaction for an existing call leg.
3.前のステップにすると、フィールドは、既存のコールレッグローカルとリモートのアドレスと比較されているから、一致するものがなかった場合。そこ試合で、かつ要求中のCSeqが最後のCSeqがその足で受信したよりも高い場合、要求は既存のコールレッグのための新しいトランザクションがあります。
12 Behavior of SIP Proxy and Redirect Servers
SIPプロキシおよびリダイレクトサーバの挙動12
This section describes behavior of SIP redirect and proxy servers in detail. Proxy servers can "fork" connections, i.e., a single incoming request spawns several outgoing (client) requests.
このセクションでは、詳細にSIPリダイレクトとプロキシサーバの動作について説明します。プロキシサーバは、すなわち、単一の着信要求は、いくつかの発信（クライアント）の要求を生成します、「フォーク」接続することができます。
A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server gathers the list of alternative locations and returns a final response of class 3xx or it refuses the request. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for the whole SIP transaction. It is up to the client to detect forwarding loops between redirect servers.
リダイレクトサーバーは、独自の任意のSIP要求を発行しません。 CANCEL以外のリクエストを受信した後、サーバは、別の場所のリストを収集し、クラス3XXの最終的な応答を返すか、要求を拒否します。 CANCEL整形リクエストの場合、それは2xx応答を返すべきです。この応答はSIPトランザクションを終了します。リダイレクトサーバーは全体のSIPトランザクションのためのトランザクション状態を維持しています。これは、リダイレクトサーバー間で転送ループを検出するために、クライアント次第です。
User agent servers behave similarly to redirect servers, except that they also accept requests and can return a response of class 2xx.
ユーザエージェントサーバは、彼らはまた、要求を受け入れ、クラス2XXの応答を返すことができることを除いて、サーバをリダイレクトするために同様に振る舞います。
This section outlines processing rules for proxy servers. A proxy server can either be stateful or stateless. When stateful, a proxy remembers the incoming request which generated outgoing requests, and the outgoing requests. A stateless proxy forgets all information once an outgoing request is generated. A forking proxy SHOULD be stateful. Proxies that accept TCP connections MUST be stateful.
このセクションでは、プロキシサーバの処理ルールの概要を説明します。プロキシサーバは、いずれかのステートフルまたはステートレスすることができます。場合ステートフルプロキシは、発信要求、送信要求を生成した着信要求を覚えています。ステートレスプロキシは、発信要求が生成されると、すべての情報を忘れました。フォークプロキシはステートフルであるべきです。 TCP接続を受け入れるプロキシは、ステートフルでなければなりません。
Otherwise, if the proxy were to lose a request, the TCP
client would never retransmit it.
A stateful proxy SHOULD NOT become stateless until after it sends a definitive response upstream, and at least 32 seconds after it received a definitive response.
それが決定的な応答を受信した後、ステートフルプロキシはそれが上流の決定的な応答を送信した後までステートレスとなり、少なくとも32秒すべきではありません。
A stateful proxy acts as a virtual UAS/UAC. It implements the server state machine when receiving requests, and the client state machine for generating outgoing requests, with the exception of receiving a 2xx response to an INVITE. Instead of generating an ACK, the 2xx response is always forwarded upstream towards the caller. Furthermore, ACK's for 200 responses to INVITE's are always proxied downstream towards the UAS, as they would be for a stateless proxy.
ステートフルプロキシは、仮想UAS / UACとして機能します。これは、リクエストを受信したときに、サーバーのステートマシンを実装し、INVITEに対する2xx応答の受信を除いて、発信要求を生成するためのクライアントステートマシン。代わりにACKを生成する、2xx応答は、常に発信者に向かってアップストリームに転送されます。彼らはステートレスプロキシのためになるようさらに、ACKの者を招待する200の応答のためには、常に、UASに向けて下流プロキシされます。
A stateless proxy does not act as a virtual UAS/UAC (as this would require state). Rather, a stateless proxy forwards every request it receives downstream, and every response it receives upstream.
ステートレスプロキシは、仮想UAS / UAC（この状態を必要とするよう）として機能しません。むしろ、ステートレスプロキシは、転送毎に、それが下流の受信要求し、それは上流の受信毎応答。
To prevent loops, a server MUST check if its own address is already contained in the Via header field of the incoming request.
自身のアドレスがすでに着信要求のViaヘッダーフィールドに含まれている場合、ループを防ぐために、サーバがチェックしなければなりません。
The To, From, Call-ID, and Contact tags are copied exactly from the original request. The proxy SHOULD change the Request-URI to indicate the server where it intends to send the request.
間では、-IDを呼び出し、連絡先タグは、元のリクエストから正確にコピーされます。プロキシは、要求を送信しようとサーバーを示すためのRequest-URIを変更する必要があります。
A proxy server always inserts a Via header field containing its own address into those requests that are caused by an incoming request. Each proxy MUST insert a "branch" parameter (Section 6.40).
プロキシサーバは、常に着信要求によって引き起こされるこれらの要求に独自のアドレスを含むViaヘッダフィールドを挿入します。各プロキシは、「ブランチ」パラメータ（セクション6.40）を挿入する必要があります。
A proxy only processes a response if the topmost Via field matches one of its addresses. A response with a non-matching top Via field MUST be dropped.
最上位のViaフィールドは、そのアドレスのいずれかに一致する場合、プロキシは応答のみを処理します。フィールド経由一致しないトップとの応答が下げなければなりません。
A stateless proxy removes its own Via field, and checks the address in the next Via field. In the case of UDP, the response is sent to the address listed in the "maddr" tag if present, otherwise to the "received" tag if present, and finally to the address in the "sent-by" field. A proxy MUST remain stateful when handling requests received via TCP.
ステートレスプロキシは、自身のViaフィールドを削除し、次のViaフィールド内のアドレスをチェックします。 UDPの場合、応答が存在する場合、そうでなければ存在する場合、最後に「送信ごとの」フィールドのアドレスに「受信」タグに「MADDR」タグに記載されているアドレスに送信されます。取り扱いリクエストはTCPを介して受信されたときにプロキシは、ステートフルままでなければなりません。
A stateless proxy MUST NOT generate its own provisional responses.
ステートレスプロキシは、独自の暫定応答を生成してはなりません。
When a stateful proxy receives a request, it checks the To, From (including tags), Call-ID and CSeq against existing request records. If the tuple exists, the request is a retransmission. The provisional or final response sent previously is retransmitted, as per the server state machine. If the tuple does not exist, the request corresponds to a new transaction, and the request should be proxied.
ステートフルプロキシはリクエストを受信すると、既存の要求レコードに対して、（タグを含む）から、コールIDとのCSeqをするためにチェックします。タプルが存在する場合は、要求が再送信です。以前に送信された仮または最終応答は、サーバ状態マシンごとに、再送信されます。タプルが存在しない場合は、リクエストが新しいトランザクションに対応し、要求がプロキシされる必要があります。
A stateful proxy server MAY generate its own provisional (1xx) responses.
ステートフルプロキシサーバは、自身の暫定（1xxの）応答を生成してもよいです。
When an ACK request is received, it is either processed locally or proxied. To make this determination, the To, From, CSeq and Call-ID fields are compared against those in previous requests. If there is no match, the ACK request is proxied as if it were an INVITE request. If there is a match, and if the server had ever sent a 200 response upstream, the ACK is proxied. If the server had never sent any responses upstream, the ACK is also proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is processed locally if the tag in the To field of the ACK matches the tag sent by the proxy in the response.
ACK要求を受信すると、それはローカルで処理またはプロキシされますか。この決意を行うために、するためには、のCSeqから、およびCall-IDをフィールドは、以前の要求のものと比較されます。一致がない場合、それはINVITE要求であるかのように、ACK要求がプロキシされます。そこに一致する場合、およびサーバは、これまで200応答上流送られていた場合、ACKがプロキシされます。サーバは、上流の応答に送信されたことがなかった場合は、ACKもプロキシされます。サーバが3XX、4XX、5xxのか6xxの応答、ない2xx応答を送っていた場合ならば、ACKはACKのToフィールド内のタグが応答したプロキシによって送信されたタグと一致して、ローカルで処理されます。
When a proxy server receives a response that has passed the Via checks, the proxy server checks the To (without the tag), From (including the tag), Call-ID and CSeq against values seen in previous requests. If there is no match, the response is forwarded upstream to the address listed in the Via field. If there is a match, the "branch" tag in the Via field is examined. If it matches a known branch identifier, the response is for the given branch, and processed by the virtual client for the given branch. Otherwise, the response is dropped.
プロキシサーバーが経由のチェックを通過した応答を受信すると、プロキシサーバは、（タグを含む）から、以前の要求で見られた値に対してとのCSeq-IDを呼び出し、（タグなし）へをチェックします。一致しない場合、応答は、Viaフィールドに記載されているアドレスに上流に転送されます。一致がある場合は、Viaフィールドの「ブランチ」タグが検討されています。それが知られているブランチ識別子と一致した場合、レスポンスが与えられた枝のためのものであり、特定のブランチのための仮想クライアントによって処理されました。そうでなければ、応答は破棄されます。
A stateful proxy should obey the rules in Section 12.4 to determine if the response should be proxied upstream. If it is to be proxied, the same rules for stateless proxies above are followed, with the following addition for TCP. If a request was received via TCP (indicated by the protocol in the top Via header), the proxy checks to see if it has a connection currently open to that address. If so, the response is sent on that connection. Otherwise, a new TCP connection is opened to the address and port in the Via field, and the response is sent there. Note that this implies that a UAC or proxy MUST be prepared to receive responses on the incoming side of a TCP connection. Definitive non 200-class responses MUST be retransmitted by the proxy, even over a TCP connection.
ステートフルプロキシは、応答が上流プロキシされるべきかどうかを決定するために、セクション12.4の規則に従うべきです。それはプロキシする場合は、上記のステートレスプロキシの同じ規則は、TCPのために、次の追加により、続いています。要求がTCP（Viaヘッダー上部にプロトコルによって示される）を介して受信された場合、プロキシは、それがそのアドレスへの現在のオープン接続を持っているかどうかをチェックします。その場合、応答はその接続で送信されます。そうでない場合は、新しいTCP接続がViaフィールド内のアドレスとポートに開放され、応答がそこに送信されます。これは、UACまたはプロキシは、TCPコネクションの入側の応答を受け取ることを準備する必要があることを意味することに注意してください。決定的な非200クラス応答でもTCP接続を介して、プロキシによって再送信されなければなりません。
Proxies in this category issue at most a single unicast request for each incoming SIP request, that is, they do not "fork" requests. However, servers MAY choose to always operate in a mode that allows issuing of several requests, as described in Section 12.4.
各着信SIP要求のための最も単一のユニキャスト要求で、このカテゴリの問題ではプロキシは、つまり、彼らはない「フォーク」の要求を行います。ただし、サーバは常に12.4項で説明したように、いくつかの要求の発行を可能にするモードで動作するように選ぶかもしれません。
The server can forward the request and any responses. It does not have to maintain any state for the SIP transaction. Reliability is assured by the next redirect or stateful proxy server in the server chain.
サーバーは、要求と応答に転送することができます。これは、SIPトランザクションのためにどのような状態を維持する必要はありません。信頼性は、サーバー・チェーン内の次のリダイレクトまたはステートフルプロキシサーバによって保証されています。
A proxy server SHOULD cache the result of any address translations and the response to speed forwarding of retransmissions. After the cache entry has been expired, the server cannot tell whether an incoming request is actually a retransmission of an older request. The server will treat it as a new request and commence another search.
プロキシサーバーは、任意のアドレス変換および再送信の高速転送への応答の結果をキャッシュすべきです。キャッシュエントリの有効期限が切れてきた後、サーバーが着信要求が実際に古い要求の再送信であるかどうかわかりません。サーバーは新しい要求としてそれを扱い、別の検索を開始します。
The server MUST respond to the request immediately with a 100 (Trying) response.
サーバは100（しよう）応答ですぐに要求に応じなければなりません。
Successful responses to an INVITE request MAY contain a Contact header field so that the following ACK or BYE bypasses the proxy search mechanism. If the proxy requires future requests to be routed through it, it adds a Record-Route header to the request (Section 6.29).
以下のACKまたはBYEプロキシ検索メカニズムを迂回するようにINVITEリクエストに成功した応答は、Contactヘッダーフィールドを含むかもしれません。プロキシは、それを経由してルーティングすることが今後の要求を必要とする場合、その要求（セクション6.29）にRecord-Routeヘッダを追加します。
The following C-code describes the behavior of a proxy server issuing several requests in response to an incoming INVITE request. The function request(r, a, b) sends a SIP request of type r to address a, with branch id b. await_response() waits until a response is received and returns the response. close(a) closes the TCP connection to client with address a. response(r) sends a response to the client. ismulticast() returns 1 if the location is a multicast address and zero otherwise. The variable timeleft indicates the amount of time left until the maximum response time has expired. The variable recurse indicates whether the server will recursively try addresses returned through a 3xx response. A server MAY decide to recursively try only certain addresses, e.g., those which are within the same domain as the proxy server. Thus, an initial multicast request can trigger additional unicast requests.
次のCコードは、着信INVITE要求に応じて、いくつかの要求を発行するプロキシ・サーバの動作を記述する。機能要求（R、B）の分岐のID Bと、対応するタイプRのSIP要求を送信します。 await_response（）は、応答を受信するまで待機し、応答を返します。クローズ（a）はアドレスAとクライアントへのTCP接続を閉じます。応答（r）は、クライアントへの応答を送信します。位置が他のマルチキャストアドレスとゼロの場合ismulticast（）は1を返します。変数timeleftには、最大応答時間が経過するまでの残り時間の量を示します。変数再帰は、再帰的にアドレスをしようとするサーバが3xx応答によって返されたかどうかを示します。サーバは、例えば、再帰的に特定のアドレスのみをしようとするプロキシサーバと同じドメイン内にあるものを決定してもよいです。したがって、最初のマルチキャスト要求は、追加のユニキャスト要求をトリガすることができます。
/* request type */
typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;
process_request(Method R, int N, address_t address[])
{
struct {
int branch; /* branch id */
int done; /* has responded */
} outgoing[];
int done[]; /* address has responded */
char *location[]; /* list of locations */
int heard = 0; /* number of sites heard from */
int class; /* class of status code */
int timeleft = 120; /* sample timeout value */
int loc = 0; /* number of locations */
struct { /* response */
int status; /* response: CANCEL=-1 */
int locations; /* number of redirect locations */
char *location[]; /* redirect locations */
address_t a; /* address of respondent */
int branch; /* branch identifier */
} r, best; /* response, best response */
int i;
best.status = 1000; for (i = 0; i < N; i++) {
best.status = 1000;用（i = 0; iがN <、iは++）{
request(R, address[i], i);
outgoing[i].done = 0;
outgoing[i].branch = i;
}
while (timeleft > 0 && heard < N) {
r = await_response();
class = r.status / 100;
/* If final response, mark branch as done. */
if (class >= 2) {
heard++;
for (i = 0; i < N; i++) {
if (r.branch == outgoing[i].branch) {
outgoing[i].done = 1;
break;
}
}
}
/* CANCEL: respond, fork and wait for responses */
else if (class < 0) {
best.status = 200;
response(best);
for (i = 0; i < N; i++) {
if (!outgoing[i].done)
request(CANCEL, address[i], outgoing[i].branch);
}
best.status = -1;
}
/* Send an ACK */
if (class != 2) { if (R == INVITE) request(ACK, r.a, r.branch); }
IF（！クラス= 2）{IF（R == INVITE）要求（ACK、r.a、r.branch）。 }
if (class == 2) {
if (r.status < best.status) best = r;
break;
}
else if (class == 3) {
/* A server MAY optionally recurse. The server MUST check
* whether it has tried this location before and whether
* the location is part of the Via path of the incoming
* request. This check is omitted here for brevity.
* Multicast locations MUST NOT be returned to the client if
* the server is not recursing.
*/
if (recurse) {
multicast = 0;
N += r.locations;
for (i = 0; i < r.locations; i++) {
request(R, r.location[i]);
}
} else if (!ismulticast(r.location)) {
best = r;
}
}
else if (class == 4) {
if (best.status >= 400) best = r;
}
else if (class == 5) {
if (best.status >= 500) best = r;
}
else if (class == 6) {
best = r;
break;
}
}
/* We haven't heard anything useful from anybody. */
if (best.status == 1000) {
best.status = 404;
}
if (best.status/100 != 3) loc = 0;
response(best);
}
Responses are processed as follows. The process completes (and state can be freed) when all requests have been answered by final status responses (for unicast) or 60 seconds have elapsed (for multicast). A proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to the client after 60 seconds or more.
次のように応答が処理されます。すべての要求は（ユニキャストのために）最終ステータス応答で回答されているか、60秒（マルチキャスト用）経過したとき、プロセスが完了（および状態を解放することができます）。プロキシは、すべての枝にキャンセルし、60秒以上後にクライアントに408（タイムアウト）を返す送るかもしれません。
1xx: The proxy MAY forward the response upstream towards the client.
1XX：プロキシはクライアントに向けて上流の応答を転送することができます。
2xx: The proxy MUST forward the response upstream towards the client, without sending an ACK downstream. After receiving a 2xx, the server MAY terminate all other pending requests by sending a CANCEL request and closing the TCP connection, if applicable. (Terminating pending requests is advisable as searches consume resources. Also, INVITE requests could "ring" on a number of workstations if the callee is currently logged in more than once.)
2XX：プロキシは、下流ACKを送信せずに、クライアントに向けて上流の応答を転送する必要があります。 2XXを受け取った後、サーバーはCANCEL要求を送信し、該当する場合は、TCP接続を閉じることにより、他のすべての保留中の要求を終了することができます。 （検索はリソースを消費して保留中の要求を終了すると、お勧めします。また、呼び出し先が現在回以上ログインしている場合、ワークステーションの数のリクエストでした「リング」をINVITE。）
3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact addresses. Otherwise, the lowest-numbered response is returned if there were no 2xx responses.
300番台：プロキシはACKを送らなければなりませんし、記載された連絡先アドレスに再帰的かもしれません。何の2xx応答がなかった場合はそうでない場合は、最も小さい番号の応答が返されます。
Location lists are not merged as that would prevent
forwarding of authenticated responses. Also, responses can
have message bodies, so that merging is not feasible.
4xx, 5xx: The proxy MUST send an ACK and remember the response if it has a lower status code than any previous 4xx and 5xx responses. On completion, the lowest-numbered response is returned if there were no 2xx or 3xx responses.
4xx、5xxの：プロキシはACKを送信し、それが以前の4xxと5xxの応答より低いステータスコードを持っている場合、応答を覚えておく必要があります。何の2xxまたは3xxの応答がなかった場合に完了すると、最も小さい番号の応答が返されます。
6xx: The proxy MUST forward the response to the client and send an ACK. Other pending requests MAY be terminated with CANCEL as described for 2xx responses.
6xx：プロキシはクライアントへの応答を転送し、ACKを送らなければなりません。 2xx応答のために説明したように、他の保留中の要求がでCANCEL終了することができます。
A proxy server forwards any response for Call-IDs for which it does not have a pending transaction according to the response's Via header. User agent servers respond to BYE requests for unknown call legs with status code 481 (Transaction Does Not Exist); they drop ACK requests with unknown call legs silently.
プロキシサーバは、応答のViaヘッダーに応じて、保留中のトランザクションを持たないためにコールIDのいずれかの応答を転送します。ユーザエージェントサーバはステータスコード481と、未知のコールレッグ（トランザクションが存在しない）のためのBYE要求に応答します。彼らは黙って、未知のコールレッグとACK要求をドロップします。
Special considerations apply for choosing forwarding destinations for ACK and BYE requests. In most cases, these requests will bypass proxies and reach the desired party directly, keeping proxies from having to make forwarding decisions.
特別な考慮事項は、ACKとBYE要求の転送先を選択するために適用されます。ほとんどの場合、これらの要求は、転送決定を下すために持っていることから、プロキシを保ち、プロキシをバイパスし、直接希望のパーティーに到達します。
A proxy MAY maintain call state for a period of its choosing. If a proxy still has list of destinations that it forwarded the last INVITE to, it SHOULD direct ACK requests only to those downstream servers.
プロキシは、その選択した期間の通話状態を維持することができます。プロキシはまだそれが最後にINVITEを転送する宛先のリストを持っている場合は、それだけで、それらのダウンストリームサーバーにACK要求を指示すべきです。
13 Security Considerations
13のセキュリティの考慮事項
SIP requests and responses can contain sensitive information about the communication patterns and communication content of individuals. The SIP message body MAY also contain encryption keys for the session itself. SIP supports three complementary forms of encryption to protect privacy:
SIP要求と応答は、通信パターンや個人の通信内容に関する機密情報を含むことができます。 SIPメッセージボディは、セッション自体の暗号化キーを含むかもしれません。 SIPは、プライバシーを保護するために暗号化の3つの補完的な形式をサポートしています。
o End-to-end encryption of the SIP message body and certain
sensitive header fields;
o hop-by-hop encryption to prevent eavesdropping that tracks who is calling whom;
Oホップ・バイ・ホップの暗号化を誰が呼び出している人を追跡盗聴を防ぐために、
o hop-by-hop encryption of Via fields to hide the route a request has taken.
OのViaフィールドのホップ・バイ・ホップの暗号化は、要求が取ったルートを非表示にします。
Not all of the SIP request or response can be encrypted end-to-end because header fields such as To and Via need to be visible to proxies so that the SIP request can be routed correctly. Hop-by-hop encryption encrypts the entire SIP request or response on the wire so that packet sniffers or other eavesdroppers cannot see who is calling whom. Hop-by-hop encryption can also encrypt requests and responses that have been end-to-end encrypted. Note that proxies can still see who is calling whom, and this information is also deducible by performing a network traffic analysis, so this provides a very limited but still worthwhile degree of protection.
このようにして経由などのヘッダーフィールドは、SIP要求を正しくルーティングできるようにプロキシに見えるようにする必要があるためではないSIP要求または応答の全ては、エンドツーエンドの暗号化することができます。パケットスニファまたは他の盗聴者が誰を呼んでいる人を見ることができないように、ホップ・バイ・ホップの暗号化は、ワイヤ上で全体のSIP要求や応答を暗号化します。ホップ・バイ・ホップの暗号化は、エンドツーエンド暗号化された要求と応答を暗号化することができます。プロキシはまだ誰呼び出しているユーザーを確認することができ、そしてこの情報は、ネットワークトラフィック分析を行うことによって推論であるので、これは保護の非常に限られたが、それでも価値のある程度を提供することに注意してください。
SIP Via fields are used to route a response back along the path taken by the request and to prevent infinite request loops. However, the information given by them can also provide useful information to an attacker. Section 6.22 describes how a sender can request that Via fields be encrypted by cooperating proxies without compromising the purpose of the Via field.
SIPのViaフィールドは応答バック要求によって取られる経路に沿ってルーティングするために使用され、無限リクエストループを防止します。しかし、それらによって与えられた情報は、攻撃者に有用な情報を提供することができます。第6.22項は、送信者が経由フィールドがViaフィールドの目的を損なうことなく、プロキシを連携することにより、暗号化されることを要求する方法について説明します。
End-to-end encryption relies on keys shared by the two user agents involved in the request. Typically, the message is sent encrypted with the public key of the recipient, so that only that recipient can read the message. All implementations SHOULD support PGP-based encryption [33] and MAY implement other schemes.
エンドツーエンドの暗号化が要求に関与する2つのユーザエージェントによって共有鍵に依存しています。それだけで受信者がメッセージを読むことができるように、一般的に、メッセージは、受信者の公開鍵で暗号化されて送信されます。すべての実装は、PGPベースの暗号化[33]をサポートする必要があり、他のスキームを実装してもよいです。
A SIP request (or response) is end-to-end encrypted by splitting the message to be sent into a part to be encrypted and a short header that will remain in the clear. Some parts of the SIP message, namely the request line, the response line and certain header fields marked with "n" in the "enc." column in Table 4 and 5 need to be read and returned by proxies and thus MUST NOT be encrypted end-to-end. Possibly sensitive information that needs to be made available as plaintext include destination address (To) and the forwarding path (Via) of the call. The Authorization header field MUST remain in the clear if it contains a digital signature as the signature is generated after encryption, but MAY be encrypted if it contains "basic" or "digest" authentication. The From header field SHOULD normally remain in the clear, but MAY be encrypted if required, in which case some proxies MAY return a 401 (Unauthorized) status if they require a From field.
SIP要求（または応答）は、エンドツーエンドのメッセージを分割することによって、暗号化が暗号化される部分と明確に残る短いヘッダに送信されます。 SIPメッセージの一部、すなわち要求ライン、応答線とに「N」でマークされた特定のヘッダフィールド「ENC」。表4と5を必要としている列が読み込まれ、プロキシによって返されるため、エンドツーエンドの暗号化されてはならないことにします。平文として利用可能にする必要がある可能性が機密情報の宛先アドレス（TO）との呼の転送経路（ビア）が挙げられます。 Authorizationヘッダフィールドは、署名が暗号化した後に生成されるように、デジタル署名が含まれている場合は明らかに残っている必要がありますが、それは認証を「ダイジェスト」「基本」が含まれる場合や、暗号化されてもよいです。 Fromヘッダフィールドは通常明確に残る必要がありますが、必要であれば、彼らはフィールドから必要な場合は、いくつかのプロキシは401（不正な）状態を返すことができ、この場合には、暗号化されてもよいです。
Other header fields MAY be encrypted or MAY travel in the clear as desired by the sender. The Subject, Allow and Content-Type header fields will typically be encrypted. The Accept, Accept-Language, Date, Expires, Priority, Require, Call-ID, Cseq, and Timestamp header fields will remain in the clear.
他のヘッダフィールドは、暗号化され得るか、または送信者が望むように平文で移動することができます。件名、許可およびContent-Typeヘッダフィールドは、通常、暗号化されます。受け入れる、受け入れ言語、日付、有効期限、優先順位、要求、コールIDを、CSEQ、およびタイムスタンプヘッダフィールド明らかに残ります。
All fields that will remain in the clear MUST precede those that will be encrypted. The message is encrypted starting with the first character of the first header field that will be encrypted and continuing through to the end of the message body. If no header fields are to be encrypted, encrypting starts with the second CRLF pair after the last header field, as shown below. Carriage return and line feed characters have been made visible as "$", and the encrypted part of the message is outlined.
明らかに残るすべてのフィールドが暗号化されるものに先行しなければなりません。メッセージが暗号化される最初のヘッダフィールドの最初の文字で始まり、メッセージ本文の最後まで継続して暗号化されます。いかなるヘッダフィールドは、以下に示すように、最後のヘッダフィールドの後に第二のCRLFペアで開始を暗号化、暗号化されていない場合。キャリッジリターンとラインフィード文字は「$」として可視化されてきた、とメッセージの暗号化された部分が概説されます。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ Via: SIP/2.0/UDP 169.130.12.5$ To: T. A. Watson <sip:watson@bell-telephone.com>$ From: A. Bell <sip:a.g.bell@bell-telephone.com>$ Encryption: PGP version=5.0$ Content-Length: 224$ Call-ID: 187602141351@worcester.bell-telephone.com$ CSeq: 488$ $ ******************************************************* * Subject: Mr. Watson, come here.$ * * Content-Type: application/sdp$ * * $ * * v=0$ * * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * * c=IN IP4 135.180.144.94$ * * m=audio 3456 RTP/AVP 0 3 4 5$ * *******************************************************
INVITE SIP：watson@boston.bell-telephone.com SIP / 2.0 $経由：SIP / 2.0 / UDP 169.130.12.5 $へ：TAワトソン<一口：watson@bell-telephone.com> $から：A.ベル<一口：agbell@bell-telephone.com> $暗号化：PGPバージョン= 5.0 $のコンテンツの長さ：224 $コールIDを：187602141351@worcester.bell-telephone.com$のCSeq：488 $ $ ******* ************************************************ *件名：ミスター・ワトソンが、ここに来て$は、* *のContent-Typeが：アプリケーション/ SDP $は、* * $ * * V = 0 $ * * oはIP4の128.3.4.5 $の鐘53655765 2353687637を= * * C IN = IP4 135.180.144.94 $ * M =オーディオ3456 RTP / AVP 0 3 4 5 $ * ********************************** *********************
An Encryption header field MUST be added to indicate the encryption mechanism used. A Content-Length field is added that indicates the length of the encrypted body. The encrypted body is preceded by a blank line as a normal SIP message body would be.
暗号化ヘッダフィールドは、使用する暗号化機構を示すために追加されなければなりません。 Content-Lengthフィールドは、暗号化されたボディの長さを示している追加されます。暗号化された本体は、本体のようになり、通常のSIPメッセージとして空白行によって先行されます。
Upon receipt by the called user agent possessing the correct decryption key, the message body as indicated by the Content-Length field is decrypted, and the now-decrypted body is appended to the clear-text header fields. There is no need for an additional Content-Length header field within the encrypted body because the length of the actual message body is unambiguous after decryption.
正しい復号鍵を有すると呼ばれるユーザエージェントによって受信すると、コンテンツ長フィールドによって示されるように、メッセージ本文を復号化され、そして今復号化ボディは、クリアテキストヘッダフィールドに付加されています。実際のメッセージ本体の長さは、復号化後の曖昧でないため、暗号化されたボディ内の追加のContent-Lengthヘッダーフィールドは必要ありません。
Had no SIP header fields required encryption, the message would have been as below. Note that the encrypted body MUST then include a blank line (start with CRLF) to disambiguate between any possible SIP header fields that might have been present and the SIP message body.
暗号化を必要としないSIPヘッダフィールドを有していなかった、メッセージは以下のとおりであったであろう。暗号化されたボディは、その後存在していたかもしれない任意の可能なSIPヘッダフィールドとSIPメッセージ本体との間に明確にするために空白行を（CRLFで始まる）を含む必要があります。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ Via: SIP/2.0/UDP 169.130.12.5$ To: T. A. Watson <sip:watson@bell-telephone.com>$ From: A. Bell <a.g.bell@bell-telephone.com>$ Encryption: PGP version=5.0$ Content-Type: application/sdp$ Content-Length: 107$ $ ************************************************* * $ * * v=0$ * * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * * c=IN IP4 135.180.144.94$ * * m=audio 3456 RTP/AVP 0 3 4 5$ * *************************************************
SIP INVITE：watson@boston.bell-telephone.comをSIP / 2.0 $経由：SIP / 2.0 / UDP 169.130.12.5 $へ：TAワトソン<一口：watson@bell-telephone.com> $から：A.ベル<AG bell@bell-telephone.com> $暗号化：PGPバージョン= 5.0 $のコンテンツタイプ：アプリケーション/ SDPの$のContent-Length：107 $ $ ******************* ****************************** * $ * * V = 0 $ * * IP4 128.3.4.5ベル53655765 2353687637 = O $ * C = IN IP4 135.180.144.94 $ * M =オーディオ3456 RTP / AVP 0 3 4 5 $ * ************************ *************************
SIP requests can be sent securely using end-to-end encryption and authentication to a called user agent that sends an insecure response. This is allowed by the SIP security model, but is not a good idea. However, unless the correct behavior is explicit, it would not always be possible for the called user agent to infer what a reasonable behavior was. Thus when end-to-end encryption is used by the request originator, the encryption key to be used for the response SHOULD be specified in the request. If this were not done, it might be possible for the called user agent to incorrectly infer an appropriate key to use in the response. Thus, to prevent key-guessing becoming an acceptable strategy, we specify that a called user agent receiving a request that does not specify a key to be used for the response SHOULD send that response unencrypted.
SIPリクエストは、安全でない応答を送信するというユーザーエージェントに、エンドツーエンドの暗号化と認証を使用して安全に送信することができます。これは、SIPのセキュリティモデルで許可されているが、良いアイデアではありません。正しい動作が明示されない限り呼ばれるユーザーエージェントは、合理的な行動が何であったかを推測するためにしかし、それは常に可能ではないでしょう。エンドツーエンドの暗号化が要求元で使用される場合したがって、応答に使用される暗号化キーは、要求に指定されるべきです。これが行われなかった場合に呼び出されるユーザーエージェントが誤って反応して使用するための適切なキーを推測することが可能かもしれません。したがって、許容可能な戦略になるキー推測を防ぐために、我々は、キーを指定していない要求を受信したというユーザーエージェントは暗号化されていないという応答を送信すべきである応答に使用するように指定します。
Any SIP header fields that were encrypted in a request SHOULD also be encrypted in an encrypted response. Contact response fields MAY be encrypted if the information they contain is sensitive, or MAY be left in the clear to permit proxies more scope for localized searches.
要求で暗号化された任意のSIPヘッダフィールドは、また、暗号化された応答で暗号化されるべきです。連絡先の応答フィールドは、そこに含まれる情報は敏感である、またはプロキシにローカライズされた検索のためのより多くの範囲を可能にするために、明確に残すことができる場合には暗号化されてもよいです。
Normally, proxies are not allowed to alter end-to-end header fields and message bodies. Proxies MAY, however, encrypt an unsigned request or response with the key of the call recipient.
通常、プロキシは、エンドツーエンドのヘッダフィールドとメッセージ本文を変更することはできません。プロキシは、しかし、コール受信者のキーで署名のない要求または応答を暗号化することができます。
Proxies need to encrypt a SIP request if the end system
cannot perform encryption or to enforce organizational
security policies.
SIP requests and responses MAY also be protected by security mechanisms at the transport or network layer. No particular mechanism is defined or recommended here. Two possibilities are IPSEC [34] or TLS [35]. The use of a particular mechanism will generally need to be specified out of band, through manual configuration, for example.
SIPリクエストとレスポンスはまた、トランスポートまたはネットワーク層でのセキュリティメカニズムによって保護されていてもよいです。いかなる特定のメカニズムは定義されていないか、ここで推奨されます。二つの可能性は、IPSEC [34]またはTLS [35]です。特定の機構の使用は、一般に、例えば、手動で設定を介して、帯域外で指定する必要があります。
When Via header fields are to be hidden, a proxy that receives a request containing an appropriate "Hide: hop" header field (as specified in section 6.22) SHOULD encrypt the header field. As only the proxy that encrypts the field will decrypt it, the algorithm chosen is entirely up to the proxy implementor. Two methods satisfy these requirements:
Viaヘッダフィールドを非表示にする場合、適当な「非表示：ホップ」を含む要求を受信プロキシヘッダフィールド（セクション6.22に指定されている）ヘッダ・フィールドを暗号化するべきです。それを解読しますフィールドを暗号化のみプロキシとして、選択されたアルゴリズムは完全にプロキシ実装に任されています。二つの方法は、これらの要件を満たします：
o The server keeps a cache of Via header fields and the
associated To header field, and replaces the Via header field
with an index into the cache. On the reverse path, take the
Via header field from the cache rather than the message.
This is insufficient to prevent message looping, and so an additional ID MUST be added so that the proxy can detect loops. This SHOULD NOT normally be the address of the proxy as the goal is to hide the route, so instead a sufficiently large random number SHOULD be used by the proxy and maintained in the cache.
これは、メッセージループを防ぐには不十分であり、プロキシがループを検出することができるようにので、追加IDを追加する必要があります。目標は、ルートを非表示にするので、代わりに十分な大きさの乱数は、プロキシによって使用され、キャッシュ内に維持されなければならないので、これは通常、プロキシのアドレスすべきではありません。
It is possible for replies to get directed to the wrong originator if the cache entry gets reused, so great care needs to be taken to ensure this does not happen.
応答がキャッシュエントリが再利用されます場合は、その偉大なケアはこれが起こらないように注意する必要があり、誤った発信者に向け取得することが可能です。
o The server MAY use a secret key to encrypt the Via field, a timestamp and an appropriate checksum in any such message with the same secret key. The checksum is needed to detect whether successful decoding has occurred, and the timestamp is required to prevent possible replay attacks and to ensure that no two requests from the same previous hop have the same encrypted Via field. This is the preferred solution.
OサーバはViaフィールド、タイムスタンプと同じ秘密鍵を持つようなメッセージで適切なチェックサムを暗号化するために、秘密鍵を使用するかもしれません。チェックサムは、復号化の成功が発生しているかどうかを検出するために必要とされ、タイムスタンプが可能リプレイ攻撃を防ぐために、同じ前のホップからの2つの要求は、フィールドで暗号化と同じを持っていないことを保証するために必要とされます。これは好ましい解決策です。
Protective measures need to be taken to prevent an active attacker from modifying and replaying SIP requests and responses. The same cryptographic measures that are used to ensure the authenticity of the SIP message also serve to authenticate the originator of the message. However, the "basic" and "digest" authentication mechanism offer authentication only, without message integrity.
保護対策は、SIPリクエストとレスポンスを変更し、再生からアクティブな攻撃を防ぐために取られる必要があります。 SIPメッセージの真正性を保証するために使用されるのと同じ暗号化対策は、メッセージの発信元を認証するのに役立ちます。メッセージの整合せず、唯一の認証メカニズムの提供認証を「ダイジェスト」しかし、「基本」と。
Transport-layer or network-layer authentication MAY be used for hop-by-hop authentication. SIP also extends the HTTP WWW-Authenticate (Section 6.42) and Authorization (Section 6.11) header field and their Proxy counterparts to include cryptographically strong signatures. SIP also supports the HTTP "basic" and "digest" schemes (see Section 14) and other HTTP authentication schemes to be defined that offer a rudimentary mechanism of ascertaining the identity of the caller.
トランスポート層やネットワーク層認証は、ホップバイホップ認証に使用されるかもしれません。 SIPは、HTTP WWW認証（セクション6.42）および許可（セクション6.11）ヘッダフィールドと、そのプロキシ対応が暗号強い署名を含むように延びています。 SIPはまた、「基本」とのスキーム（セクション14を参照）、他のHTTP認証スキームは、発信者の身元を確認する基本的なメカニズムを提供するように定義されるように、「ダイジェスト」HTTPをサポートしています。
Since SIP requests are often sent to parties with which no
prior communication relationship has existed, we do not
specify authentication based on shared secrets.
SIP requests MAY be authenticated using the Authorization header field to include a digital signature of certain header fields, the request method and version number and the payload, none of which are modified between client and called user agent. The Authorization header field is used in requests to authenticate the request originator end-to-end to proxies and the called user agent, and in responses to authenticate the called user agent or proxies returning their own failure codes. If required, hop-by-hop authentication can be provided, for example, by the IPSEC Authentication Header.
SIPリクエストは、クライアントと呼ばれるユーザーエージェント間で変更されているいずれもの特定のヘッダフィールドのデジタル署名、リクエストメソッドとバージョン番号とペイロードを含むようにAuthorizationヘッダフィールドを使用して認証することができます。 Authorizationヘッダフィールドは要求元のエンドツーエンドのプロキシへと呼ばれるユーザエージェントを認証するための要求で使用され、そして応答で呼び出されるユーザエージェント又は代理人が自分の失敗コードを返す認証します。必要な場合、ホップバイホップ認証は、IPSec認証ヘッダによって、例えば、提供することができます。
SIP does not dictate which digital signature scheme is used for authentication, but does define how to provide authentication using PGP in Section 15. As indicated above, SIP implementations MAY also use "basic" and "digest" authentication and other authentication mechanisms defined for HTTP. Note that "basic" authentication has severe security limitations. The following does not apply to these schemes.
SIPは、デジタル署名方式は、認証に使用される決定しないが、上記で示したように、セクション15でPGPを使用して認証を提供する方法を定義しない、SIP実装は、HTTPのために定義された「基本」および「ダイジェスト」認証やその他の認証メカニズムを使用するかもしれ。 「基本」認証は厳しいセキュリティ制限があることに注意してください。以下は、これらの方式には適用されません。
To cryptographically sign a SIP request, the order of the SIP header fields is important. When an Authorization header field is present, it indicates that all header fields following the Authorization header field have been included in the signature. Therefore, hop-by-hop header fields which MUST or SHOULD be modified by proxies MUST precede the Authorization header field as they will generally be modified or added-to by proxy servers. Hop-by-hop header fields which MAY be modified by a proxy MAY appear before or after the Authorization header. When they appear before, they MAY be modified by a proxy. When they appear after, they MUST NOT be modified by a proxy. To sign a request, a client constructs a message from the request method (in upper case) followed, without LWS, by the SIP version number, followed, again without LWS, by the request headers to be signed and the message body. The message thus constructed is then signed.
SIPリクエストを署名暗号ために、SIPヘッダフィールドの順序は重要です。 Authorizationヘッダフィールドが存在する場合、それはAuthorizationヘッダフィールドに続くすべてのヘッダーフィールドが署名に含まれていることを示しています。それらは一般的にプロキシサーバによって変更または付加にするようにAuthorizationヘッダフィールドに先行しなければならない必要がある、またはプロキシによって変更する必要があり、したがって、ホップバイホップヘッダフィールド。プロキシによって修飾することができるホップバイホップヘッダフィールドは、Authorizationヘッダの前または後に表示されることがあります。彼らは前に現れたとき、彼らはプロキシによって修飾され得ます。彼らは後に表示されたとき、彼らはプロキシによって変更してはいけません。要求に署名するために、クライアントは、署名されるべき要求ヘッダとメッセージ本体によって、LWSことなく再び、SIPバージョン番号によって、LWSことなく、その後に続く（大文字で）リクエストメソッドからメッセージを構築します。このように構成されたメッセージは署名されています。
For example, if the SIP request is to be:
例えば、SIP要求があることがあります。
INVITE sip:watson@boston.bell-telephone.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 Authorization: PGP version=5.0, signature=... From: A. Bell <sip:a.g.bell@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com> Call-ID: 187602141351@worcester.bell-telephone.com Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: ...
watson@boston.bell-telephone.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5認証：PGPバージョン= 5.0、署名= ...から：A.ベル<一口：agbell @ベルSIPのINVITE telephone.com>へ：TAワトソン<一口：watson@bell-telephone.com>コールID：187602141351@worcester.bell-telephone.com件名：ミスター・ワトソンは、ここに来ます。コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：...
v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5
V = 0 0 =ベル53655765 2353687637 IN IP4 128.3.4.5 C = IN IP4 135.180.144.94 M =オーディオ3456 RTP / AVP 0 3 4 5
Then the data block that is signed is:
次いで、署名されたデータブロックです。
INVITESIP/2.0From: A. Bell <sip:a.g.bell@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com> Call-ID: 187602141351@worcester.bell-telephone.com Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: ...
INVITESIP / 2.0From：A.ベル<一口：agbell@bell-telephone.com>へ：TAワトソン<一口：watson@bell-telephone.com>コールID：187602141351@worcester.bell-telephone.com件名：氏ワトソンは、ここに来ます。コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：...
v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5
V = 0 0 =ベル53655765 2353687637 IN IP4 128.3.4.5 C = IN IP4 135.180.144.94 M =オーディオ3456 RTP / AVP 0 3 4 5
Clients wishing to authenticate requests MUST construct the portion of the message below the Authorization header using a canonical form. This allows a proxy to parse the message, take it apart, and reconstruct it, without causing an authentication failure due to extra white space, for example. Canonical form consists of the following rules:
要求を認証することを望むクライアントは、標準形式を使用して、Authorizationヘッダ以下メッセージの一部を構成しなければなりません。これは、プロキシは、メッセージを解析離れてそれを取る、それを再構築、例えば、余分な空白による認証失敗を引き起こすことなくすることを可能にします。正規の形式は、次のルールで構成されています。
o No short form header fields
Oいいえショートフォームヘッダフィールド
o Header field names are capitalized as shown in this document
この文書で示すように、Oヘッダフィールド名は大文字で
o No white space between the header name and the colon
ヘッダ名とコロンの間に空白O
o A single space after the colon
コロンの後に単一のスペースO
o Line termination with a CRLF
CRLFとOライン終端
o No line folding
ノーライン折りたたみO
o No comma separated lists of header values; each must appear as a separate header
ヘッダ値の無コンマ区切りリストOであり;それぞれが別々のヘッダーとして現れなければなりません
o Only a single SP between tokens, between tokens and quoted strings, and between quoted strings; no SP after last token or quoted string
トークンの間、トークンと引用文字列の間、および引用符で囲まれた文字列の間にOのみシングルSP。最後のトークンまたは引用符で囲まれた文字列の後にはSPません
o No LWS between tokens and separators, except as described above for after the colon in header fields
ヘッダフィールドでコロンの後のために上記のよう以外トークンとセパレータとの間にLWS、いいえO
Note that if a message is encrypted and authenticated using a digital signature, when the message is generated encryption is performed before the digital signature is generated. On receipt, the digital signature is checked before decryption.
メッセージが暗号化およびデジタル署名を用いて認証された場合、デジタル署名が生成される前に、メッセージが生成され、暗号化が行われることに留意されたいです。領収書には、デジタル署名を復号化する前にチェックされています。
A client MAY require that a server sign its response by including a Require: org.ietf.sip.signed-response request header field. The client indicates the desired authentication method via the WWW-Authenticate header.
org.ietf.sip.signed応答をリクエストヘッダフィールド：クライアントは、サーバーが必要を含むことにより、その応答に署名することを要求することができます。クライアントは、WWW-Authenticateヘッダを介して所望の認証方法を示しています。
The correct behavior in handling unauthenticated responses to a request that requires authenticated responses is described in section 13.2.1.
認証された応答を必要とする要求に認証されていない応答を処理する際の正しい動作は、セクション13.2.1で説明されています。
There is the possibility that an eavesdropper listens to requests and then injects unauthenticated responses that terminate, redirect or otherwise interfere with a call. (Even encrypted requests contain enough information to fake a response.)
盗聴者が要求に耳を傾け、その後、終了リダイレクトまたはその他の呼び出しに干渉する認証されていない応答を注入している可能性があります。 （でも、暗号化された要求は、偽の応答に十分な情報が含まれています。）
Clients need to be particularly careful with 3xx redirection responses. Thus a client receiving, for example, a 301 (Moved Permanently) which was not authenticated when the public key of the called user agent is known to the client, and authentication was requested in the request SHOULD be treated as suspicious. The correct behavior in such a case would be for the called-user to form a dated response containing the Contact field to be used, to sign it, and give this signed stub response to the proxy that will provide the redirection. Thus the response can be authenticated correctly. A client SHOULD NOT automatically redirect such a request to the new location without alerting the user to the authentication failure before doing so.
クライアントは、の3xxリダイレクト応答では特に注意する必要があります。従って、クライアント受信、例えば、301は、呼び出されたユーザエージェントの公開鍵がクライアントに知られているときに認証されなかった、そして認証が疑わしいとして扱われるべき要求で要求された（永続的に移動します）。このような場合の正しい動作は、使用する連絡先フィールドを含む日付応答を形成するためにそれに署名し、リダイレクションを提供するプロキシに、この署名されたスタブの応答を与えると呼ばれる、ユーザーのためになります。したがって、応答が正しく認証することができます。クライアントは自動的にそうする前に認証失敗にユーザに警告することなく、新しい場所にそのような要求をリダイレクトすべきではありません。
Another problem might be responses such as 6xx failure responses which would simply terminate a search, or "4xx" and "5xx" response failures.
もう一つの問題は、単に検索、または「4XX」と「5xxの」応答の失敗を終了させる6xxの障害応答として応答かもしれません。
If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as valid, as they will not terminate a search. However, fake 6xx responses from a rogue proxy terminate a search incorrectly. 6xx responses SHOULD be authenticated if requested by the client, and failure to do so SHOULD cause such a client to ignore the 6xx response and continue a search.
TCPが使用されている場合、彼らは検索を終了しないように、プロキシは、有効なものとしての4xxと5xxのレスポンスを扱うべきです。しかし、不正なプロキシから偽の6xx応答が間違って検索を終了します。クライアントによって要求された場合の6xx応答が認証されるべきであり、そうしないと、このようなクライアントは、6xxの応答を無視して、検索を継続するようになります。
With UDP, the same problem with 6xx responses exists, but also an active eavesdropper can generate 4xx and 5xx responses that might cause a proxy or client to believe a failure occurred when in fact it did not. Typically 4xx and 5xx responses will not be signed by the called user agent, and so there is no simple way to detect these rogue responses. This problem is best prevented by using hop-by-hop encryption of the SIP request, which removes any additional problems that UDP might have over TCP.
UDPでは、6xxの応答と同じ問題が存在しますが、また、アクティブな盗聴者は、プロキシまたはクライアントが、実際にはそれがなかったときに障害が発生したと信じてすることがありますの4xxと5xxの応答を生成することができます。通常の4xxと5xxの応答が呼ばれるユーザエージェントによって署名されず、そのためこれらの不正な応答を検出するための簡単な方法はありません。この問題は、最高のUDPはTCPの上に持っている可能性のある追加の問題を取り除くSIPリクエストのホップバイホップ暗号化を使用することによって阻止されます。
These attacks are prevented by having the client require response authentication and dropping unauthenticated responses. A server user agent that cannot perform response authentication responds using the normal Require response of 420 (Bad Extension).
これらの攻撃は、クライアントがレスポンス認証を必要有し、かつ未認証の応答をドロップすることによって阻止されます。レスポンス認証を行うことができないサーバ・ユーザ・エージェント420（悪い拡張）の通常の要求応答を用いて応答します。
User location and SIP-initiated calls can violate a callee's privacy. An implementation SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers.
ユーザーの場所とSIPが開始するコールは、呼び出し先のプライバシーを侵害することができます。実装は、発信者の特定のクラスに配られる位置および可用性情報の種類、ユーザごとに、制限することができるべきです。
With either TCP or UDP, a denial of service attack exists by a rogue proxy sending 6xx responses. Although a client SHOULD choose to ignore such responses if it requested authentication, a proxy cannot do so. It is obliged to forward the 6xx response back to the client. The client can then ignore the response, but if it repeats the request it will probably reach the same rogue proxy again, and the process will repeat.
TCPまたはUDPのいずれかで、サービス拒否攻撃はの6xx応答を送信する不正なプロキシによって存在しています。それが認証を要求した場合、クライアントはそのような応答を無視することを選択する必要がありますが、プロキシはそうすることができません。クライアントに戻すの6xx応答を転送する義務があります。その後、クライアントは応答を無視することができますが、それは要求を繰り返した場合、それはおそらく、再び同じ不正なプロキシに到達し、プロセスが繰り返されます。
14 SIP Authentication using HTTP Basic and Digest Schemes
HTTP Basicおよびダイジェストスキームを使用して14 SIP認証
SIP implementations MAY use HTTP's basic and digest authentication mechanisms to provide a rudimentary form of security. This section overviews usage of these mechanisms in SIP. The basic operation is almost completely identical to that for HTTP [36]. This section outlines this operation, pointing to [36] for details, and noting the differences when used in SIP.
SIPの実装では、HTTPの基本を使用して、セキュリティの基本的な形態を提供する認証メカニズムを消化するかもしれません。 SIPにおけるこれらのメカニズムのこのセクションの概要の使用。基本的な動作は、HTTP [36]の場合とほぼ完全に同一です。このセクションでは、詳細については[36]を指し、この操作を概説し、SIPで使用する場合の違いを指摘しました。
The framework for SIP authentication parallels that for HTTP [36]. In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical. The 401 response is used by user agent servers in SIP to challenge the authorization of a user agent client. Additionally, registrars and redirect servers MAY make use of 401 responses for authorization, but proxies MUST NOT, and instead MAY use the 407 response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages is identical to [36].
SIP認証のフレームワークは、HTTP [36]のために匹敵します。具体的には、AUTH-スキーム、AUTH-PARAM、チャレンジ、レルム、レルム値、および資格情報のBNFは同一です。 401応答は、ユーザエージェントクライアントの認証に挑戦するSIPにユーザエージェントサーバによって使用されます。また、登録機関およびサーバをリダイレクトは、認可のための401個の応答を利用することができるが、プロキシはならず、代わりに407応答を使用するかもしれません。様々なメッセージ中のプロキシ認証、プロキシ認証、WWW認証、および認可を含めるための要件は[36]と同じです。
Since SIP does not have the concept of a canonical root URL, the notion of protections spaces are interpreted differently for SIP. The realm is a protection domain for all SIP URIs with the same value for the userinfo, host and port part of the SIP Request-URI. For example:
SIPは正規のルートURLの概念がありませんので、保護空間の概念は、SIPのために異なって解釈されています。レルムはSIP要求URIのuserinfoを、ホストとポートの部分に同じ値を持つすべてのSIP URIの保護ドメインです。例えば：
INVITE sip:alice.wonderland@example.com SIP/2.0 WWW-Authenticate: Basic realm="business"
INVITE SIP：alice.wonderland@example.com SIP / 2.0 WWW認証：基本レルム= "ビジネス"
and
そして
INVITE sip:aw@example.com SIP/2.0 WWW-Authenticate: Basic realm="business"
INVITE SIP：aw@example.com SIP / 2.0 WWW認証：基本レルム= "ビジネス"
define different protection realms according to this rule.
このルールに応じて、異なる保護レルムを定義します。
When a UAC resubmits a request with its credentials after receiving a 401 or 407 response, it MUST increment the CSeq header field as it would normally do when sending an updated request.
UACが401または407応答を受信した後に、その資格情報を使用して要求を再送信したときに更新要求を送信するときに通常行うように、それはCSeqヘッダーフィールドをインクリメントしなければなりません。
The rules for basic authentication follow those defined in [36], but with the words "origin server" replaced with "user agent server, redirect server , or registrar".
基本的な認証のためのルールは、[36]で定義されたものに従うが、で置換単語「オリジンサーバ」と「ユーザ・エージェント・サーバ、サーバ、またはレジストラをリダイレクトします」。
Since SIP URIs are not hierarchical, the paragraph in [36] that states that "all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge" does not apply for SIP. SIP clients MAY preemptively send the corresponding Authorization header with requests for SIP URIs within the same protection realm (as defined above) without receipt of another challenge from the server.
SIP URIは、すべてのパスまたは要求URIのパス・フィールドの最後の象徴的要素の深さよりも深いが、基本的なレルムによって指定された保護空間内にある」と述べている[36]で段落の階層ではありませんので、現在の課題の値は、」SIPには適用されません。 （上記で定義したような）SIPクライアントは、先制サーバから別のチャレンジを受信することなく、同一の保護領域内でSIP URIのための要求に対応するAuthorizationヘッダを送信することができます。
The rules for digest authentication follow those defined in [36], with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following differences:
ダイジェスト認証のためのルールは、次の相違点に加えて、「SIP / 2.0」に置き換え、「HTTP 1.1」で、で定義されたもの[36]、次のとおりです。
URI = SIP-URL
URI = SIP URL
digest-uri-value = Request-URI ; a defined in Section
4.3
3. The example procedure for choosing a nonce based on Etag does not work for SIP.
3.たEtagに基づいてnonceを選択するための手順例では、SIPのために動作しません。
4. The Authentication-Info and Proxy-Authentication-Info fields are not used in SIP.
4.認証-INFOとプロキシ認証-INFOフィールドは、SIPで使用されていません。
5. The text in [36] regarding cache operation does not apply to SIP.
5.キャッシュ操作について[36]内のテキストは、SIPには適用されません。
6. [36] requires that a server check that the URI in the request line, and the URI included in the Authorization header, point to the same resource. In a SIP context, these two URI's may actually refer to different users, due to forwarding at some proxy. Therefore, in SIP, a server MAY check that the request-uri in the Authorization header corresponds to a user that the server is willing to accept forwarded or direct calls for.
6. [36]同じリソースにリクエストラインのURI、およびURIがAuthorizationヘッダに含まれるそのサーバのチェックポイントを必要とします。 SIPコンテキストでは、これらの2つのURIのは、実際に何らかのプロキシに転送するには、別のユーザーを参照してもよいです。したがって、SIPで、サーバは、要求URI Authorizationヘッダには、サーバが転送のために、または直接呼び出しを受け入れても構わないと思っているユーザに対応することを確認することができます。
The use of the Proxy-Authentication and Proxy-Authorization parallel that as described in [36], with one difference. Proxies MUST NOT add the Proxy-Authorization header. 407 responses MUST be forwarded upstream towards the client following the procedures for any other response. It is the client's responsibility to add the Proxy-Authorization header containing credentials for the proxy which has asked for authentication.
ような一つの違いで、[36]に記載されているプロキシ認証およびプロキシ認証平行の使用。プロキシはプロキシ認証ヘッダーを追加してはなりません。 407の応答は、他の応答のための手順に従って、クライアントに向けて上流に転送する必要があります。認証のために求めているプロキシの資格情報を含むProxy-Authorizationヘッダーを追加するために、クライアントの責任です。
If a proxy were to resubmit a request with a Proxy-
Authorization header field, it would need to increment the
CSeq in the new request. However, this would mean that the
UAC which submitted the original request would discard a
response from the UAS, as the CSeq value would be
different.
See sections 6.26 and 6.27 for additional information on usage of these fields as they apply to SIP.
彼らはSIPに適用されるセクションにこれらのフィールドの使用方法に関する追加情報は、6.26と6.27を参照してください。
15 SIP Security Using PGP
PGPを使用して15 SIPセキュリティ
The "pgp" authentication scheme is based on the model that the client authenticates itself with a request signed with the client's private key. The server can then ascertain the origin of the request if it has access to the public key, preferably signed by a trusted third party.
「PGP」認証スキームは、クライアントは、クライアントの秘密鍵で署名要求に自身を認証モデルに基づいています。それは、好ましくは、信頼できるサードパーティが署名した公開鍵へのアクセスを持っている場合、サーバは、要求の発信元を確認することができます。
WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge
pgp-challenge = * (";" pgp-params )
pgp-params = realm | pgp-version | pgp-algorithm | nonce
realm = "realm" "=" realm-value
realm-value = quoted-string
pgp-version = "version" "="
<"> digit *( "." digit ) *letter <">
pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token )
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
The meanings of the values of the parameters used above are as follows:
以下のように使用されるパラメータの値の意味は以下のとおりです。
realm: A string to be displayed to users so they know which identity to use. This string SHOULD contain at least the name of the host performing the authentication and MAY additionally indicate the collection of users who might have access. An example might be " Users with call-out privileges ".
分野：彼らは、使用するアイデンティティを知っているので、ユーザに表示される文字列。この文字列は、少なくとも認証を実行するホストの名前が含まれている必要があり、さらにアクセス権を持っている可能性があるユーザーの収集を指示することができます。例は、「コールアウト権限を持つユーザー」であるかもしれません。
pgp-algorithm: The value of this parameter indicates the PGP message integrity check (MIC) to be used to produce the signature. If this not present it is assumed to be "md5". The currently defined values are "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
PGPアルゴリズム：このパラメータの値は、署名を生成するために使用されるPGPメッセージ完全性チェック（MIC）を示しています。これが存在しない場合には「MD5」であると想定されます。現在定義された値はSHA.1アルゴリズムのMD5チェックサムのための「MD5」、および「SHA1」です。
pgp-version: The version of PGP that the client MUST use. Common values are "2.6.2" and "5.0". The default is 5.0.
PGPバージョン：クライアントが使用しなければならないPGPのバージョン。一般的な値は、「2.6.2」と「5.0」です。デフォルトは5.0です。
nonce: A server-specified data string which should be uniquely generated each time a 401 response is made. It is RECOMMENDED that this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string, the double-quote character is not allowed. The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. Since the nonce is used only to prevent replay attacks and is signed, a time stamp in units convenient to the server is sufficient.
ノンス一意401応答が行われるたびに生成されるべきサーバが指定したデータ列。この文字列をbase64でまたは16進数のデータであることが推奨されます。文字列は引用符で囲まれた文字列としてヘッダ行に渡されているので具体的には、二重引用符文字は許可されていません。ナンスの内容は実装に依存しています。実装の品質は良い選択に依存します。ナンスは、リプレイ攻撃を防ぐためにのみ使用され、署名されているので、サーバーへの便利な単位のタイムスタンプは十分です。
Replay attacks within the duration of the call setup are of
limited interest, so that timestamps with a resolution of a
few seconds are often should be sufficient. In that case,
the server does not have to keep a record of the nonces.
Example:
例：
WWW-Authenticate: pgp ;version="5.0" ;realm="Your Startrek identity, please" ;algorithm=md5 ;nonce="913082051"
WWW認証：PGP;バージョン= "5.0";領域= "あなたのスタートレックのアイデンティティ、してください";アルゴリズム= MD5;ナンス= "913082051"
The client is expected to retry the request, passing an Authorization header line, which is defined as follows.
クライアントは、次のように定義されているAuthorizationヘッダラインを通過し、要求を再試行することが期待されます。
Authorization = "Authorization" ":" "pgp" *( ";" pgp-response )
pgp-response = realm | pgp-version | pgp-signature
| signed-by | nonce
pgp-signature = "signature" "=" quoted-string
signed-by = "signed-by" "=" <"> URI <">
The client MUST increment the CSeq header before resubmitting the request. The signature MUST correspond to the From header of the request unless the signed-by parameter is provided.
クライアントが要求を再送信する前のCSeqヘッダを増加しなければなりません。ログインして、パラメータが提供されない限り、署名は、リクエストのFromヘッダに対応しなければなりません。
pgp-signature: The PGP ASCII-armored signature [33], as it appears between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" delimiters, without the version indication. The signature is included without any linebreaks.
PGP署名：PGPのASCII装甲署名[33]、それはバージョン表示することなく、および「ENDのPGPメッセージ」区切り文字「PGPメッセージをBEGIN」の間に表示されます。署名は、任意の改行せずに含まれます。
The signature is computed across the nonce (if present), request method, request version and header fields following the Authorization header and the message body, in the same order as they appear in the message. The request method and version are prepended to the header fields without any white space. The signature is computed across the headers as sent, and the terminating CRLF. The CRLF following the Authorization header is NOT included in the signature.
署名は、それらがメッセージに現れるのと同じ順序で、Authorizationヘッダとメッセージ本体以下ナンス（存在する場合）、リクエストメソッド、リクエストのバージョンとヘッダフィールドを横切って計算されます。要求方法及びバージョンは、任意の空白なしにヘッダフィールドの先頭に付加されています。署名は、送信されたヘッダ、及び終端CRLFを横切って計算されます。 Authorizationヘッダ次のCRLFは、署名に含まれていません。
A server MAY be configured not to generate nonces only if replay attacks are not a concern.
サーバーは、リプレイ攻撃が懸念されない場合にのみ、ナンスを生成しないようにしてもよいです。
Not generating nonces avoids the additional set of request,
401 response and possibly ACK messages and reduces delay by
one round-trip time.
Using the ASCII-armored version is about 25% less space-efficient than including the binary signature, but it is significantly easier for the receiver to piece together. Versions of the PGP program always include the full (compressed) signed text in their output unless ASCII-armored mode ( -sta ) is specified. Typical signatures are about 200 bytes long. -- The PGP signature mechanism allows the client to simply pass the request to an external PGP program. This relies on the requirement that proxy servers are not allowed to reorder or change header fields.
ASCII装甲バージョンを使用してバイナリの署名を含む、より空間効率の約25％以下であるが、それは一緒にピースに受信機のための大幅に容易です。 PGPプログラムのバージョンが常に含まフル（圧縮）ASCII形式のモード（-sta）が指定されていない限り、それらの出力にテキストに署名しました。典型的な署名は約200バイト長です。 - PGP署名メカニズムは、クライアントが単に外部PGPプログラムに要求を渡すことができます。これは、プロキシサーバは、ヘッダフィールドを並べ替えたり、変更することはできません要件に依存しています。
realm: The realm is copied from the corresponding WWW-Authenticate header field parameter.
レルム：レルムは、対応するWWW-Authenticateヘッダフィールドパラメータからコピーされます。
signed-by: If and only if the request was not signed by the entity listed in the From header, the signed-by header indicates the name of the signing entity, expressed as a URI.
署名されたバイ：要求がFromヘッダに記載されているエンティティによって署名されていなかった場合のみ、署名されたバイヘッダ署名エンティティの名前を示す場合、URIとして表さ。
Receivers of signed SIP messages SHOULD discard any end-to-end header fields above the Authorization header, as they may have been maliciously added en route by a proxy.
それらは悪意プロキシによって途中で添加されていてもよいように署名されたSIPメッセージの受信機は、Authorizationヘッダ上の任意のエンドツーエンドのヘッダフィールドを破棄すべきです。
Example:
例：
Authorization: pgp version="5.0" ;realm="Your Startrek identity, please" ;nonce="913082051" ;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX =aIrx"
認証：PGPバージョン= "5.0";領域= "あなたのスタートレックのアイデンティティ、してください";ナンス= "913082051";署名= "iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL / Wt3dk6TWK81 / b0gcNDf VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC + KLFX = aIrx"
The PGP encryption scheme uses the following syntax:
PGPの暗号化方式には、次の構文を使用します。
Encryption = "Encryption" ":" "pgp" pgp-eparams
pgp-eparams = 1# ( pgp-version | pgp-encoding )
pgp-encoding = "encoding" "=" "ascii" | token
encoding: Describes the encoding or "armor" used by PGP. The value "ascii" refers to the standard PGP ASCII armor, without the lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and without the version identifier. By default, the encrypted part is included as binary.
エンコーディング：PGPが使用するエンコーディングや「鎧」を記述します。値「ASCII」と「ENDのPGPメッセージ」とバージョン識別子なし「PGPメッセージをBEGIN」含む行することなく、標準PGPのASCII装甲を指します。デフォルトでは、暗号化された部分は、バイナリとして含まれています。
Example:
例：
Encryption: pgp version="2.6.2", encoding="ascii"
暗号化：PGPバージョン= "2.6.2"、エンコーディング= "ASCII"
Response-Key = "Response-Key" ":" "pgp" pgp-eparams
pgp-eparams = 1# ( pgp-version | pgp-encoding | pgp-key)
pgp-key = "key" "=" quoted-string
If ASCII encoding has been requested via the encoding parameter, the key parameter contains the user's public key as extracted from the pgp key ring with the "pgp -kxa user ".
ASCIIエンコーディングは、符号化パラメータを介して要求された場合には、重要なパラメータは、「PGPの-kxaユーザー」とPGP鍵リングから抽出されたように、ユーザーの公開鍵が含まれています。
Example:
例：
Response-Key: pgp version="2.6.2", encoding="ascii", key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu bmVAY3MuY29sdW1iaWEuZWR1Pg== =+y19"
応答キー：PGPバージョン= "2.6.2"、エンコーディング= "ASCII"、キー= "mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG + ItYK5tCF8HNJM60sU4rLaV + eUnkMk mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu bmVAY3MuY29sdW1iaWEuZWR1Pg == = + Y19"
16 Examples
16例
In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type headers for brevity.
次の例では、私たちはしばしば、メッセージ本文と簡潔にするため、対応するコンテンツの長さとのContent-Typeヘッダを省略します。
A user at host saturn.bell-tel.com registers on start-up, via multicast, with the local SIP server named bell-tel.com. In the example, the user agent on saturn expects to receive SIP requests on UDP port 3890.
ホストのユーザーsaturn.bell-tel.comはbell-tel.comという名前のローカルSIPサーバに、マルチキャストを経由して、起動時に登録されます。例では、saturnのユーザエージェントは、UDPポート3890でSIP要求を受信することを期待します。
C->S: REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:watson@bell-tel.com To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp> Expires: 7200
C-> S：bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP saturn.bell-tel.comから：SIP：watson@bell-tel.comへ：SIP：ベルTEL @ワトソン一口を登録.COMコールID：70710@saturn.bell-tel.comはのCSeq：1 REGISTER連絡先：<SIP：watson@saturn.bell-tel.com：3890;運輸= udpの>は有効期限：7200
The registration expires after two hours. Any future invitations for watson@bell-tel.com arriving at sip.bell-tel.com will now be redirected to watson@saturn.bell-tel.com, UDP port 3890.
登録は2時間後に期限が切れます。 sip.bell-tel.comに到着watson@bell-tel.comための任意の将来の招待状は、現在、UDPポート3890 watson@saturn.bell-tel.comにリダイレクトされます。
If Watson wants to be reached elsewhere, say, an on-line service he uses while traveling, he updates his reservation after first cancelling any existing locations:
ワトソンは、他の場所に到達することを希望する場合は、旅行中に彼が使用してのオンラインサービスは、彼が最初に既存の位置をキャンセルした後、彼の予約を更新し、言います：
C->S: REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:watson@bell-tel.com To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 2 REGISTER Contact: * Expires: 0
C-> S：bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP saturn.bell-tel.comから：SIP：watson@bell-tel.comへ：SIP：ベルTEL @ワトソン一口を登録.COMコールID：70710@saturn.bell-tel.comのCSeq：2 REGISTER連絡先：*有効期限：0
C->S: REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: sip:watson@bell-tel.com To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 3 REGISTER Contact: sip:tawatson@example.com
C-> S：bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP saturn.bell-tel.comから：SIP：watson@bell-tel.comへ：SIP：ベルTEL @ワトソン一口を登録.COMコールID：70710@saturn.bell-tel.comのCSeq：3 REGISTERお問い合わせ：SIP：tawatson@example.com
Now, the server will forward any request for Watson to the server at example.com, using the Request-URI tawatson@example.com. For the server at example.com to reach Watson, he will need to send a REGISTER there, or inform the server of his current location through some other means.
さて、サーバーは、Request-URI tawatson@example.comを使用して、example.comのサーバにワトソンのためのすべての要求を転送します。 example.comのサーバがワトソンに到達するために、彼はそこにREGISTERを送ったり、他の手段を通じて彼の現在の場所のサーバーに通知する必要があります。
It is possible to use third-party registration. Here, the secretary jon.diligent registers his boss, T. Watson:
サードパーティの登録を使用することが可能です。ここでは、彼の上司を登録jon.diligent秘書、T.ワトソン：
C->S: REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP pluto.bell-tel.com From: sip:jon.diligent@bell-tel.com To: sip:watson@bell-tel.com Call-ID: 17320@pluto.bell-tel.com CSeq: 1 REGISTER Contact: sip:tawatson@example.com
C-> S：鐘@ワトソン：bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP pluto.bell-tel.comから：SIP：jon.diligent@bell-tel.comへ：一口一口を登録-tel.comコールID：17320@pluto.bell-tel.comのCSeq：1つのREGISTER連絡先：SIP：tawatson@example.com
The request could be sent to either the registrar at bell-tel.com or the server at example.com. In the latter case, the server at example.com would proxy the request to the address indicated in the Request-URI. Then, Max-Forwards header could be used to restrict the registration to that server.
リクエストはexample.comでbell-tel.comでレジストラまたはサーバに送信することができます。後者の場合には、example.comのサーバは、プロキシアドレスへの要求は、Request-URIに示されるであろう。次いで、最大Forwardsヘッダは、そのサーバへの登録を制限するために使用することができます。
The first example invites schooler@vlsi.cs.caltech.edu to a multicast session. All examples use the Session Description Protocol (SDP) (RFC 2327 [6]) as the session description format.
最初の例では、マルチキャストセッションにschooler@vlsi.cs.caltech.eduを招きます。全ての実施例は、セッション記述形式として、セッション記述プロトコル（SDP）（RFC 2327 [6]）を使用します。
C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 ;maddr=239.128.16.254;ttl=16 Via: SIP/2.0/UDP north.east.isi.edu From: Mark Handley <sip:mjh@isi.edu> To: Eve Schooler <sip:schooler@caltech.edu> Call-ID: 2963313058@north.east.isi.edu CSeq: 1 INVITE Subject: SIP will be discussed, too Content-Type: application/sdp Content-Length: 187
C-> S：INVITE SIP：schooler@cs.caltech.eduのSIP / 2.0経由：SIP / 2.0 / UDP csvax.cs.caltech.edu;分岐= 8348; MADDR = 239.128.16.254; TTL = 16を介し：SIP / 2.0 / UDP north.east.isi.eduから：マーク・ハンドリー<一口：mjh@isi.edu>へ：イブ学生は<一口：schooler@caltech.edu>コールID：2963313058@north.east.isi.eduのCSeq ：1件名をINVITE：SIPが議論される、あまりにものContent-Type：アプリケーション/ SDPコンテンツの長さ：187
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
The From request header above states that the request was initiated by mjh@isi.edu and addressed to schooler@caltech.edu (From header fields). The Via fields list the hosts along the path from invitation initiator (the last element of the list) towards the callee. In the example above, the message was last multicast to the administratively scoped group 239.128.16.254 with a ttl of 16 from the host csvax.cs.caltech.edu. The second Via header field indicates that it was originally sent from the host north.east.isi.edu. The Request-URI indicates that the request is currently being being addressed to schooler@cs.caltech.edu, the local address that csvax looked up for the callee.
上記リクエストヘッダからの要求がmjh@isi.eduによって開始され、（ヘッダフィールドから）schooler@caltech.eduにアドレスされたことを述べています。ビアフィールドは被呼者に向けて招待開始剤（リストの最後の要素）から経路に沿ってホストをリストします。上記の例では、メッセージは、ホストcsvax.cs.caltech.eduから16のTTLと管理スコープグループ239.128.16.254への最後のマルチキャストました。 Viaヘッダーフィールド目は、それが最初にホストnorth.east.isi.eduから送信されたことを示しています。 Request-URIが要求は、現在、呼び出し先のために見上げcsvaxローカルアドレスをschooler@cs.caltech.eduするためにアドレス指定されていることを示します。
In this case, the session description is using the Session Description Protocol (SDP), as stated in the Content-Type header.
Content-Typeヘッダに記載されているように、この場合に、セッション記述は、セッション記述プロトコル（SDP）を使用しています。
The header is terminated by an empty line and is followed by a message body containing the session description.
ヘッダは空行で終了し、セッション記述を含むメッセージ本体が続きます。
The called user agent, directly or indirectly through proxy servers, indicates that it is alerting ("ringing") the called party:
呼ばれるユーザーエージェントは、直接的または間接的に、プロキシサーバーを介し、呼ばれるパーティーを（「リンギング」）警告されていることを示します。
S->C: SIP/2.0 180 Ringing Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 ;maddr=239.128.16.254;ttl=16 Via: SIP/2.0/UDP north.east.isi.edu From: Mark Handley <sip:mjh@isi.edu> To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472 Call-ID: 2963313058@north.east.isi.edu CSeq: 1 INVITE
S-> C：SIP / 2.0 180リンギングのVia：SIP / 2.0 / UDP csvax.cs.caltech.edu;分岐= 8348; MADDR = 239.128.16.254; TTL = 16を介し：SIP / 2.0 / UDP north.east.isi .eduの投稿者：マーク・ハンドリー<一口：mjh@isi.edu>へ：イブ学生は<一口：schooler@caltech.edu>;タグ= 9883472のCall-ID：2963313058@north.east.isi.eduのCSeq：1 INVITE
A sample response to the invitation is given below. The first line of the response states the SIP version number, that it is a 200 (OK) response, which means the request was successful. The Via headers are taken from the request, and entries are removed hop by hop as the response retraces the path of the request. A new authentication field MAY be added by the invited user's agent if required. The Call-ID is taken directly from the original request, along with the remaining fields of the request message. The original sense of From field is preserved (i.e., it is the session initiator).
招待に対するサンプルの応答を以下に示します。応答の最初の行は、要求が成功したことを意味する200（OK）応答であることを、SIPバージョン番号を述べています。応答は、要求の経路を引き返すようにホップすることによってホップのViaヘッダはリクエストから取得され、そしてエントリが除去されます。必要に応じて新しい認証フィールドには、招待されたユーザーのエージェントによって追加される場合があります。コールIDは、要求メッセージの残りのフィールドとともに、元の要求から直接取得されます。フィールドが保存されているから、元の感覚（すなわち、セッション開始剤です）。
In addition, the Contact header gives details of the host where the user was located, or alternatively the relevant proxy contact point which should be reachable from the caller's host.
また、Contactヘッダは、ユーザが位置していたホスト、または発信者のホストから到達可能でなければならない代わりに、関連するプロキシ接点の詳細を与えます。
S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 ;maddr=239.128.16.254;ttl=16 Via: SIP/2.0/UDP north.east.isi.edu From: Mark Handley <sip:mjh@isi.edu> To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472 Call-ID: 2963313058@north.east.isi.edu CSeq: 1 INVITE Contact: sip:es@jove.cs.caltech.edu
S-> C：SIP / 2.0 200 OK経由：SIP / 2.0 / UDP csvax.cs.caltech.edu;分岐= 8348; MADDR = 239.128.16.254; TTL = 16を介し：SIP / 2.0 / UDP north.east.isi .eduの投稿者：マーク・ハンドリー<一口：mjh@isi.edu>へ：イブ学生は<一口：schooler@caltech.edu>;タグ= 9883472のCall-ID：2963313058@north.east.isi.eduのCSeq：連絡先を1 INVITE ：SIP：es@jove.cs.caltech.edu
The caller confirms the invitation by sending an ACK request to the location named in the Contact header:
発信者は、Contactヘッダで指定された場所にACKリクエストを送信することによって招待を確認します。
C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0 Via: SIP/2.0/UDP north.east.isi.edu From: Mark Handley <sip:mjh@isi.edu> To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472 Call-ID: 2963313058@north.east.isi.edu CSeq: 1 ACK
C-> S：ACK SIP：es@jove.cs.caltech.edu SIP / 2.0経由：SIP / 2.0 / UDP north.east.isi.eduから：マーク・ハンドリー<一口：mjh@isi.edu>へ：イブ小学生<SIP：schooler@caltech.edu>;タグ= 9883472のCall-ID：2963313058@north.east.isi.eduのCSeq：1 ACK
For two-party Internet phone calls, the response must contain a description of where to send the data. In the example below, Bell calls Watson. Bell indicates that he can receive RTP audio codings 0 (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).
二大政党のインターネット電話の場合は、応答は、データの送信先の記述が含まれている必要があります。以下の例では、ベルはワトソンを呼び出します。ベルは、彼がRTPオーディオコーディング0（PCMU）、3（GSM）、4（G.723）および5（DVI4）を受け取ることができることを示しています。
C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: ...
C-> S：INVITE SIP：watson@boston.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com >へ：T.ワトソン<一口：watson@bell-tel.com>は、コールIDを：3298420296@kton.bell-tel.comのCSeq：1件名を招待：ミスターワトソンは、ここに来ます。コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
c=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0 3 4 5
S->C: SIP/2.0 100 Trying Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Content-Length: 0
S-> C：SIP / 2.0経由を試し100：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com>から：T.ワトソン<SIP：・ワトソン@ bell-tel.com>;タグは= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：1は、コンテンツの長さをINVITE：0
S->C: SIP/2.0 180 Ringing Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Content-Length: 0
S-> C：SIP / 2.0 180リンギングのVia：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com>から：T.ワトソン<SIP：・ワトソン@ bell-tel.com>;タグは= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：1は、コンテンツの長さをINVITE：0
S->C: SIP/2.0 182 Queued, 2 callers ahead Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Content-Length: 0
S-> C：SIP / 2.0 182キュー、先にビア2人の発信者：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com>から：T.ワトソン<SIP：watson@bell-tel.com>;タグ= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：コンテンツ長をINVITE 1：0
S->C: SIP/2.0 182 Queued, 1 caller ahead Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Content-Length: 0
S-> C：先に経由SIP / 2.0 182キュー、1発信者：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com>から：T.ワトソン<SIP：watson@bell-tel.com>;タグ= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：コンテンツ長をINVITE 1：0
S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Contact: sip:watson@boston.bell-tel.com Content-Type: application/sdp Content-Length: ...
S-> C：SIP / 2.0 200 OK経由：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<一口：agbell@bell-tel.com>宛先：<SIP：ワトソン@ベルtel.com>;タグ= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：1は、連絡先をINVITE：SIP：watson@boston.bell-tel.comのContent-Type：アプリケーション/ SDPのContent-Length：。 。..
v=0
o=watson 4858949 4858949 IN IP4 192.1.2.3
s=I'm on my way
c=IN IP4 boston.bell-tel.com
m=audio 5004 RTP/AVP 0 3
The example illustrates the use of informational status responses. Here, the reception of the call is confirmed immediately (100), then, possibly after some database mapping delay, the call rings (180) and is then queued, with periodic status updates.
例では、情報のステータス応答の使用を示します。ここで、呼び出しの受信は、次いで、（100）直ちに確認される可能性がいくつかのデータベースマッピング遅延の後、コールリング（180）と、その後定期的ステータス更新と、キューに入れられています。
Watson can only receive PCMU and GSM. Note that Watson's list of codecs may or may not be a subset of the one offered by Bell, as each party indicates the data types it is willing to receive. Watson will send audio data to port 3456 at c.bell-tel.com, Bell will send to port 5004 at boston.bell-tel.com.
ワトソンはPCMUとGSMを受け取ることができます。各当事者は、受け取るために喜んでデータ型を示してコーデックのワトソンのリストは、または、ベルが提供する1のサブセットであってもなくてもよいことに注意してください。ワトソンは、ベルがboston.bell-tel.comでポート5004に送信されます、c.bell-tel.comでポート3456への音声データを送信します。
By default, the media session is one RTP session. Watson will receive RTCP packets on port 5005, while Bell will receive them on port 3457.
デフォルトでは、メディアセッションは、1つのRTPセッションです。ベルは、ポート3457上でそれらを受け取ることになりますしながら、ワトソンは、ポート5005上のRTCPパケットを受信します。
Since the two sides have agreed on the set of media, Bell confirms the call without enclosing another session description:
双方は、メディアのセットに合意しているので、ベルは別のセッション記述を囲むことなく、通話を確認します：
C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 ACK
C-> S：ACK SIP：watson@boston.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com >から：T.ワトソン<SIP：watson@bell-tel.com>;タグ= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：1 ACK
To terminate a call, caller or callee can send a BYE request:
通話を終了するには、発信者または呼び出し先がBYE要求を送信することができます。
C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 2 BYE
C-> S：BYE SIP：watson@boston.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP kton.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com >から：TAワトソン<SIP：watson@bell-tel.com>;タグ= 37462311のCall-ID：3298420296@kton.bell-tel.comのCSeq：2 BYE
If the callee wants to abort the call, it simply reverses the To and From fields. Note that it is unlikely that a BYE from the callee will traverse the same proxies as the original INVITE.
呼び出し先が呼び出しを中止したい場合、それは単にへとフィールドから反転します。呼び出し先からBYEはオリジナルと同じプロキシがINVITEを行き来することはほとんどありませんので注意してください。
In this example, Bell (a.g.bell@bell-tel.com) (C), currently seated at host c.bell-tel.com wants to call Watson (t.watson@ieee.org). At the time of the call, Watson is logged in at two workstations, t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has registered with the IEEE proxy server (P) called sip.ieee.org. The IEEE server also has a registration for the home machine of Watson, at watson@h.bell-tel.com (H), as well as a permanent registration at watson@acm.org (A). For brevity, the examples omit the session description and Via header fields.
この例では、現在ホストc.bell-tel.comに座っベル（a.g.bell@bell-tel.com）（C）は、ワトソン（t.watson@ieee.org）を呼び出すしたいと考えています。呼び出し時に、ワトソンは2台のワークステーション、t.watson@x.bell-tel.com（X）とwatson@y.bell-tel.com（Y）にログインして、IEEEプロキシに登録されていますサーバー（P）はsip.ieee.orgと呼ばれます。 IEEEサーバもwatson@h.bell-tel.comでワトソンの自宅のマシンの登録、（H）と同様に、watson@acm.orgで永久登録（A）を持っています。簡潔にするために、実施例は、セッション記述とヘッダフィールドを介しを省略します。
Bell's user agent sends the invitation to the SIP server for the ieee.org domain:
ベルのユーザエージェントはieee.orgドメインのSIPサーバへの招待状を送信します。
C->P: INVITE sip:t.watson@ieee.org SIP/2.0 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
C-> P：SIPのINVITE：SIP / 2.0を介してt.watson@ieee.org：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<一口：agbell@bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>コールID：31415@c.bell-tel.comのCSeq：1 INVITE
The SIP server at ieee.org tries the four addresses in parallel. It sends the following message to the home machine:
ieee.orgでSIPサーバを並列に4つのアドレスをしようとします。これは、自宅のマシンに次のメッセージを送信します。
P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
P-> H：INVITE SIP：watson@h.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP sip.ieee.org;分岐= 1を介し：SIP / 2.0 / UDP c.bell-tel.com投稿者：A.ベル<一口：agbell@bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>コールID：31415@c.bell-tel.comのCSeq：1 INVITE
This request immediately yields a 404 (Not Found) response, since Watson is not currently logged in at home:
ワトソンは現在、自宅でログインしていないので、この要求は、直ちに、404（Not Found）応答を得られます。
H->P: SIP/2.0 404 Not Found Via: SIP/2.0/UDP sip.ieee.org ;branch=1 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
H-> P：SIP / 2.0 404を介して見つかりませんでした：SIP / 2.0 / UDP sip.ieee.orgを、ブランチ= 1ビア：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<SIP：AG bell@bell-tel.com>から：T.ワトソン<SIP：t.watson@ieee.org>;タグ= 87454273
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
The proxy ACKs the response so that host H can stop retransmitting it:
応答のACKプロキシホストHがそれを再送停止することができるように：
P->H: ACK sip:watson@h.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=87454273 Call-ID: 31415@c.bell-tel.com CSeq: 1 ACK
P-> H：ACKのSIP：watson@h.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP sip.ieee.org;ブランチ= 1から：A.ベル<一口：agbell @ベルTEL .COM>から：T.ワトソン<SIP：t.watson@ieee.org>;タグ= 87454273のCall-ID：31415@c.bell-tel.comのCSeq：1 ACK
Also, P attempts to reach Watson through the ACM server:
また、Pは、ACMサーバを介してワトソンに到達しようとします。
P->A: INVITE sip:watson@acm.org SIP/2.0 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
P-> A：SIPのINVITE：watson@acm.org SIP / 2.0経由：SIP / 2.0 / UDP sip.ieee.org;分岐= 2を介し：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>コールID：31415@c.bell-tel.comのCSeq：1 INVITE
In parallel, the next attempt proceeds, with an INVITE to X and Y:
XとYにINVITEと並行して、次の試行の進行：
P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP sip.ieee.org ;branch=3 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
P-> X：INVITE SIP：t.watson@x.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP sip.ieee.org;分岐= 3を介し：SIP / 2.0 / UDP c.bell-TEL .COMから：A.ベル<一口：agbell@bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>コールID：31415@c.bell-tel.comのCSeq： 1 INVITE
P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP sip.ieee.org ;branch=4 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
P-> Y：INVITE SIP：watson@y.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP sip.ieee.org;分岐= 4を介し：SIP / 2.0 / UDP c.bell-tel.com投稿者：A.ベル<一口：agbell@bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>コールID：31415@c.bell-tel.comのCSeq：1 INVITE
As it happens, both Watson at X and a colleague in the other lab at host Y hear the phones ringing and pick up. Both X and Y return 200s via the proxy to Bell.
偶然にも、Xの両方でワトソンとホストYで、他の研究室の同僚が鳴って電話を聞いて拾います。ベルへのプロキシ経由の両方のXとYのリターン200S。
X->P: SIP/2.0 200 OK Via: SIP/2.0/UDP sip.ieee.org ;branch=3 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> ;tag=192137601 Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE Contact: sip:t.watson@x.bell-tel.com
X-> P：SIP / 2.0 200 OK経由：SIP / 2.0 / UDP sip.ieee.org;ブランチ= 3ビア：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<SIP：agbell @ bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>;タグ= 192137601コールID：31415@c.bell-tel.comのCSeq：連絡先を1 INVITE：SIP：トンを。 watson@x.bell-tel.com
Y->P: SIP/2.0 200 OK Via: SIP/2.0/UDP sip.ieee.org ;branch=4 Via: SIP/2.0/UDP c.bell-tel.com Contact: sip:t.watson@y.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> ;tag=35253448 Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE
Y-> P：SIP / 2.0 200 OK経由：SIP / 2.0 / UDP sip.ieee.org;ブランチ= 4を介して：SIP / 2.0 / UDP c.bell-tel.comお問い合わせ：SIP：t.watson@y。 bell-tel.comから：A.ベル<一口：agbell@bell-tel.com>へ：T.ワトソン<一口：t.watson@ieee.org>;タグ= 35253448のCall-ID：C @ 31415。 bell-tel.comのCSeq：1 INVITE
Both responses are forwarded to Bell, using the Via information. At this point, the ACM server is still searching its database. P can now cancel this attempt:
両方の応答は、経由情報を使用して、ベルに転送されます。この時点で、ACMサーバは、まだそのデータベースを検索します。 Pは今、この試みをキャンセルすることができます。
P->A: CANCEL sip:watson@acm.org SIP/2.0 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org> Call-ID: 31415@c.bell-tel.com CSeq: 1 CANCEL
P-> A：watson@acm.org SIP / 2.0経由：SIP CANCEL;へagbell@bell-tel.com>：SIP / 2.0 / UDP sip.ieee.orgからブランチ= 2：A.ベル<一口：T.ワトソン<一口：t.watson@ieee.org>コールID：31415@c.bell-tel.comのCSeq：1はCANCEL
The ACM server gladly stops its neural-network database search and responds with a 200. The 200 will not travel any further, since P is the last Via stop.
ACMサーバーは喜んでそのニューラルネットワークのデータベース検索を停止し、Pは最後の経由が停止しているので、さらに任意の旅行ません200 200で応答します。
A->P: SIP/2.0 200 OK Via: SIP/2.0/UDP sip.ieee.org ;branch=2 From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>
A-> P：SIP / 2.0 200 OK経由：SIP / 2.0 / UDP sip.ieee.org;分岐= 2：A.ベル<SIP：agbell@bell-tel.com>から：T.ワトソン<SIP ：t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 CANCEL
Bell gets the two 200 responses from X and Y in short order. Bell's reaction now depends on his software. He can either send an ACK to both if human intelligence is needed to determine who he wants to talk to or he can automatically reject one of the two calls. Here, he acknowledges both, separately and directly to the final destination:
ベルは短いために、XとYの2つの200の応答を取得します。ベルの反応は今、彼のソフトウェアに依存します。彼は、人間の知性は彼が話をしたい者を決定するために必要とされる両方の場合にACKを送信するか、または彼が自動的に2つの呼び出しのいずれかを拒否することができます。ここで、彼は最終的な宛先に個別に直接、両方を認めます：
C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=192137601 Call-ID: 31415@c.bell-tel.com CSeq: 1 ACK
C-> X：ACK SIP：t.watson@x.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<一口：agbell @ベルTEL .COM>から：T.ワトソン<SIP：t.watson@ieee.org>;タグ= 192137601のCall-ID：31415@c.bell-tel.comのCSeq：1 ACK
C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=35253448 Call-ID: 31415@c.bell-tel.com CSeq: 1 ACK
C-> Y：ACK SIP：watson@y.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com >から：T.ワトソン<SIP：t.watson@ieee.org>;タグ= 35253448のCall-ID：31415@c.bell-tel.comのCSeq：1 ACK
After a brief discussion between Bell with X and Y, it becomes clear that Watson is at X. (Note that this is not a three-way call; only Bell can talk to X and Y, but X and Y cannot talk to each other.) Thus, Bell sends a BYE to Y, which is replied to:
XとYとベルとの簡単な説明の後、これは3方向通話ではないことに注意してください（ワトソンがX.であることが明らかになり、唯一のベルは、XとYに話すことができますが、XとYはお互いに話すことができません。）このように、ベルはに答えているYにBYEを送信します。
C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=35253448 Call-ID: 31415@c.bell-tel.com CSeq: 2 BYE
C-> Y：BYE SIP：watson@y.bell-tel.com SIP / 2.0経由：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com >から：T.ワトソン<SIP：t.watson@ieee.org>;タグ= 35253448のCall-ID：31415@c.bell-tel.comのCSeq：2 BYE
Y->C: SIP/2.0 200 OK Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=35253448 Call-ID: 31415@c.bell-tel.com CSeq: 2 BYE
Y-> C：SIP / 2.0 200 OK経由：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<一口：agbell@bell-tel.com>へ：T.ワトソン<SIP：トン.watson @ ieee.org>;タグ= 35253448のCall-ID：31415@c.bell-tel.comのCSeq：2 BYE
Replies with status codes 301 (Moved Permanently) or 302 (Moved Temporarily) specify another location using the Contact field. Continuing our earlier example, the server P at ieee.org decides to redirect rather than proxy the request:
連絡先フィールドを使用して別の場所を指定し、ステータスコード301（恒久的に移動）または302（一時的に移動）で応答します。私たちの以前の例を続けると、ieee.orgのサーバPは、要求をリダイレクトするのではなく、プロキシすることを決定しました。
P->C: SIP/2.0 302 Moved temporarily Via: SIP/2.0/UDP c.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:t.watson@ieee.org>;tag=72538263 Call-ID: 31415@c.bell-tel.com CSeq: 1 INVITE Contact: sip:watson@h.bell-tel.com, sip:watson@acm.org, sip:t.watson@x.bell-tel.com, sip:watson@y.bell-tel.com CSeq: 1 INVITE
P-> C：SIP / 2.0 302を介して一時的に移動：SIP / 2.0 / UDP c.bell-tel.comから：A.ベル<SIP：agbell@bell-tel.com>から：T.ワトソン<SIP： t.watson@ieee.org>;タグ= 72538263のCall-ID：31415@c.bell-tel.comのCSeq：1連絡先をINVITE：SIP：watson@h.bell-tel.com、SIP：watson@acm.org 、SIP：t.watson@x.bell-tel.com、SIP：watson@y.bell-tel.comのCSeq：1 INVITE
As another example, assume Alice (A) wants to delegate her calls to Bob (B) while she is on vacation until July 29th, 1998. Any calls meant for her will reach Bob with Alice's To field, indicating to him what role he is to play. Charlie (C) calls Alice (A), whose server returns:
別の例として、彼はどのような役割彼に示し、アリス（A）は、彼女が7月29日まで休暇にある間、彼女のために意味1998年の呼び出しは、アリスの持つボブは、フィールドには到達しますボブ（B）に彼女の呼び出しを委任したいと仮定再生します。チャーリー（C）は、そのサーバ戻るアリス（A）を、呼び出し：
A->C: SIP/2.0 302 Moved temporarily From: Charlie <sip:charlie@caller.com> To: Alice <sip:alice@anywhere.com> ;tag=2332462 Call-ID: 27182@caller.com Contact: sip:bob@anywhere.com Expires: Wed, 29 Jul 1998 9:00:00 GMT CSeq: 1 INVITE
A-> C：チャーリー<SIP：charlie@caller.com>から：アリス<SIP：SIP / 2.0 302から一時的に移動alice@anywhere.com>;タグ= 2332462のCall-ID：27182@caller.com接触。 SIP：bob@anywhere.com有効期限：水曜日、1998年7月29日9時00分00秒GMTのCSeqを：1 INVITE
Charlie then sends the following request to the SIP server of the anywhere.com domain. Note that the server at anywhere.com forwards the request to Bob based on the Request-URI.
チャーリーはその後、anywhere.comドメインのSIPサーバに次の要求を送信します。 anywhere.comのサーバが要求URIに基づいてボブに要求を転送していることに注意してください。
C->B: INVITE sip:bob@anywhere.com SIP/2.0 From: sip:charlie@caller.com To: sip:alice@anywhere.com Call-ID: 27182@caller.com CSeq: 2 INVITE
C-> B：INVITE SIP：bob@anywhere.com SIP / 2.0：SIP：charlie@caller.comに：SIP：alice@anywhere.comコールID：27182@caller.comのCSeq：INVITE 2
In the third redirection example, we assume that all outgoing requests are directed through a local firewall F at caller.com, with Charlie again inviting Alice:
第三リダイレクトの例では、我々はすべての送信要求がチャーリーは再びアリスを招いて、caller.comでローカルファイアウォールFを介して導かれていることを前提としています。
C->F: INVITE sip:alice@anywhere.com SIP/2.0 From: sip:charlie@caller.com To: Alice <sip:alice@anywhere.com> Call-ID: 27182@caller.com CSeq: 1 INVITE
C-> F：alice@anywhere.com SIP / 2.0：SIP：charlie@caller.comに：アリス<SIP：alice@anywhere.com>コールID：SIPのINVITE 27182@caller.comのCSeq：INVITE 1
The local firewall at caller.com happens to be overloaded and thus redirects the call from Charlie to a secondary server S:
caller.comでのローカルファイアウォールが過負荷状態にすることを起こるので、セカンダリサーバSへのチャーリーからのコールをリダイレクトします。
F->C: SIP/2.0 302 Moved temporarily From: sip:charlie@caller.com To: Alice <sip:alice@anywhere.com> Call-ID: 27182@caller.com CSeq: 1 INVITE Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
F-> C：SIP / 2.0から一時的に移動302：SIP：charlie@caller.comに：アリス<SIP：alice@anywhere.com>コール番号：27182@caller.comのCSeq：接触INVITE 1：<SIP： alice@anywhere.com：5080; MADDR = spare.caller.com>
Based on this response, Charlie directs the same invitation to the secondary server spare.caller.com at port 5080, but maintains the same Request-URI as before:
この応答に基づいて、チャーリーは、ポート5080でのセカンダリサーバspare.caller.comに同じ招待を指示したが、前と同じのRequest-URIを維持します。
C->S: INVITE sip:alice@anywhere.com SIP/2.0 From: sip:charlie@caller.com To: Alice <sip:alice@anywhere.com> Call-ID: 27182@caller.com CSeq: 2 INVITE
C-> S：alice@anywhere.com SIP / 2.0：SIP：charlie@caller.comに：アリス<SIP：alice@anywhere.com>コールID：SIPのINVITE 27182@caller.comのCSeq：INVITE 2
An example of a 606 (Not Acceptable) response is:
606（許容できない）応答の例を示します。
S->C: SIP/2.0 606 Not Acceptable From: sip:mjh@isi.edu To: <sip:schooler@cs.caltech.edu> ;tag=7434264 Call-ID: 14142@north.east.isi.edu
S-> C：SIP / 2.0 606れていないから許容：SIP：mjh@isi.eduに<SIP：schooler@cs.caltech.edu>;タグは= 7434264のCall-ID：14142@north.east.isi.edu
CSeq: 1 INVITE
Contact: sip:mjh@north.east.isi.edu
Warning: 370 "Insufficient bandwidth (only have ISDN)",
305 "Incompatible media format",
330 "Multicast not available"
Content-Type: application/sdp
Content-Length: 50
v=0 s=Let's talk b=CT:128 c=IN IP4 north.east.isi.edu m=audio 3456 RTP/AVP 5 0 7 m=video 2232 RTP/AVP 31
V = 0 S = CT =さんがBをお話しましょう：128 C IN = IP4 north.east.isi.eduメートル=オーディオ3456 RTP / AVP 5 0 7メートル=ビデオ2232 RTP / AVP 31
In this example, the original request specified a bandwidth that was higher than the access link could support, requested multicast, and requested a set of media encodings. The response states that only 128 kb/s is available and that (only) DVI, PCM or LPC audio could be supported in order of preference.
この例では、元の要求は、アクセスリンクより高かった帯域幅をサポートすることができ、指定されたマルチキャストを要求し、メディアエンコーディングのセットを要求しました。応答は、128キロバイト/ sが利用可能であり、その（のみ）DVI、PCMまたはLPCオーディオを優先順に支持することができることを述べています。
The response also states that multicast is not available. In such a case, it might be appropriate to set up a transcoding gateway and re-invite the user.
応答は、マルチキャストが利用できないと述べています。このような場合には、トランスコーディングゲートウェイ、再招待ユーザーを設定することが適切かもしれません。
A caller Alice can use an OPTIONS request to find out the capabilities of a potential callee Bob, without "ringing" the designated address. Bob returns a description indicating that he is capable of receiving audio encodings PCM Ulaw (payload type 0), 1016 (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic payload type 99), and video encodings H.261 (payload type 31) and H.263 (payload type 34).
呼び出し側は、アリスは、指定されたアドレスを「リンギング」せずに、潜在的な呼び出し先ボブの能力を調べるためにOPTIONS要求を使用することができます。ボブは、彼がH PCM ULAW（ペイロードタイプ0）、1016（ペイロードタイプ1）、GSM（ペイロードタイプ3）、及びSX7300 / 8000（ダイナミックペイロードタイプ99）、及びビデオ符号化オーディオエンコーディングを受信することが可能であることを示す記述を返します0.261（ペイロードタイプ31）とH.263（ペイロードタイプ34）。
C->S: OPTIONS sip:bob@example.com SIP/2.0 From: Alice <sip:alice@anywhere.org> To: Bob <sip:bob@example.com> Call-ID: 6378@host.anywhere.org CSeq: 1 OPTIONS Accept: application/sdp
C-> S：OPTIONS SIP：bob@example.com SIP / 2.0：アリス<SIP：alice@anywhere.org>から：ボブ<SIP：bob@example.com>コールID：6378@host.anywhere。組織のCSeq：1つのOPTIONSは受け入れ：アプリケーション/ SDP
S->C: SIP/2.0 200 OK From: Alice <sip:alice@anywhere.org> To: Bob <sip:bob@example.com> ;tag=376364382
S-> C：TO alice@anywhere.org>：ボブ<SIP：アリス<SIP：からSIP / 2.0 200 OK bob@example.com>;タグ= 376364382
Call-ID: 6378@host.anywhere.org
Content-Length: 81
Content-Type: application/sdp
v=0 m=audio 0 RTP/AVP 0 1 3 99 m=video 0 RTP/AVP 31 34 a=rtpmap:99 SX7300/8000
V = 0、M = 0オーディオRTP / AVP 0 1 3 99、M =ビデオ0 RTP / AVP 31 34 = rtpmap：99 SX7300 / 8000
A Minimal Implementation
最小限の実装
A.1 Client
A.1クライアント
All clients MUST be able to generate the INVITE and ACK requests. Clients MUST generate and parse the Call-ID, Content-Length, Content-Type, CSeq, From and To headers. Clients MUST also parse the Require header. A minimal implementation MUST understand SDP (RFC 2327, [6]). It MUST be able to recognize the status code classes 1 through 6 and act accordingly.
すべてのクライアントは、INVITEとACK要求を生成することができなければなりません。クライアントは、Fromヘッダーとするために呼び出す-ID、コンテンツの長さ、Content-Typeの、のCSeqを生成して解析する必要があります。また、クライアントはRequireヘッダーを解析する必要があります。最小限の実装では、SDP（RFC 2327 [6]）を理解しなければなりません。 6を介してステータスコードクラス1を認識し、それに応じて行動することができなければなりません。
The following capability sets build on top of the minimal implementation described in the previous paragraph. In general, each capability listed below builds on the ones above it:
以下の機能セットは、前の段落で説明した最小限の実装の上に構築します。一般的には、以下に示す各機能は、それ以上のものに基づいています：
Basic: A basic implementation adds support for the BYE method to allow the interruption of a pending call attempt. It includes a User-Agent header in its requests and indicates its preferred language in the Accept-Language header.
基本：基本的な実装では、保留中のコール試行の中断を可能にするためにBYEメソッドのサポートを追加します。それは、そのリクエストのUser-Agentヘッダが含まれており、受け入れ言語をヘッダ内にその言語を示します。
Redirection: To support call forwarding, a client needs to be able to understand the Contact header, but only the SIP-URL part, not the parameters.
リダイレクト：通話転送をサポートするには、クライアントはContactヘッダーが、唯一のSIP-URLの一部ではなく、パラメータを理解できるようにする必要があります。
Firewall-friendly: A firewall-friendly client understands the Route and Record-Route header fields and can be configured to use a local proxy for all outgoing requests.
ファイアウォールに優しい：ファイアウォールフレンドリーなクライアントは、ルートおよびRecord-Routeヘッダーフィールドを理解し、すべての発信要求に対してローカルプロキシを使用するように設定することができます。
Negotiation: A client MUST be able to request the OPTIONS method and understand the 380 (Alternative Service) status and the Contact parameters to participate in terminal and media negotiation. It SHOULD be able to parse the Warning response header to provide useful feedback to the caller.
交渉：クライアントはOPTIONSメソッドを要求し、端末とメディア交渉に参加するために380（代替サービス）の状態と連絡先のパラメータを理解できなければなりません。呼び出し元に有用なフィードバックを提供するために、警告応答ヘッダを解析することができるべきです。
Authentication: If a client wishes to invite callees that require caller authentication, it MUST be able to recognize the 401 (Unauthorized) status code, MUST be able to generate the Authorization request header and MUST understand the WWW-Authenticate response header.
認証：クライアントは、発信者の認証を必要と呼び出し先を招待したい場合、それは401（不正な）ステータスコードを認識できなければなりません、認可要求ヘッダを生成することができなければならなくて、WWW認証応答ヘッダを理解しなければなりません。
If a client wishes to use proxies that require caller authentication, it MUST be able to recognize the 407 (Proxy Authentication Required) status code, MUST be able to generate the Proxy-Authorization request header and understand the Proxy-Authenticate response header.
クライアントは、発信者の認証を必要とするプロキシを使用したい場合、407（プロキシ認証が必要）ステータスコードを認識できなければなりません、プロキシ認証要求ヘッダーを生成し、プロキシ認証応答ヘッダーを理解できなければなりません。
A.2 Server
A.2サーバー
A minimally compliant server implementation MUST understand the INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also understand CANCEL. It MUST parse and generate, as appropriate, the Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-Forwards, Require, To and Via headers. It MUST echo the CSeq and Timestamp headers in the response. It SHOULD include the Server header in its responses.
最小限に準拠したサーバの実装は、INVITE、ACK、OPTIONSとBYE要求を理解する必要があります。プロキシサーバは、CANCELを理解する必要があります。これは、解析し、生成し、必要に応じて、コールID、コンテンツの長さ、Content-Typeの、のCSeqは、有効期限、マックス・フォワード、から、し、ヘッダを経由して、要求する必要があります。これは、応答のCSeqとタイムスタンプのヘッダーをエコーしなければなりません。それは、その応答でサーバーヘッダーを含むべきです。
A.3 Header Processing
A.3ヘッダー処理
Table 6 lists the headers that different implementations support. UAC refers to a user-agent client (calling user agent), UAS to a user-agent server (called user-agent).
表6の異なる実装がサポートヘッダー。 UACは、ユーザエージェントクライアント（ユーザーエージェントを呼び出す）、ユーザエージェントサーバへのUASは（ユーザーエージェントと呼ばれる）を指します。
The fields in the table have the following meaning. Type is as in Table 4 and 5. "-" indicates the field is not meaningful to this system (although it might be generated by it). "m" indicates the field MUST be understood. "b" indicates the field SHOULD be understood by a Basic implementation. "r" indicates the field SHOULD be understood if the system claims to understand redirection. "a" indicates the field SHOULD be understood if the system claims to support authentication. "e" indicates the field SHOULD be understood if the system claims to support encryption. "o" indicates support of the field is purely optional. Headers whose support is optional for all implementations are not shown.
テーブルのフィールドには、次のような意味を持っています。タイプ表4および5と同様である「 - 」（それによって生成されるかもしれないが）フィールドがこのシステムにとって意味のないことを示します。 「M」はフィールドが理解されなければならない示します。 「b」は、フィールドは、基本的な実装が理解されるべきであることを示します。 「R」は、システムがリダイレクトを理解するために主張する場合フィールドが理解されるべきで示します。 「システム」が認証をサポートするために主張する場合フィールドが理解されるべきで示します。 「e」は、システムが暗号化をサポートするために主張した場合、フィールドには理解されるべきであることを示します。 「o」はフィールドのサポートは純粋にオプションであることを示します。そのサポートすべての実装のためのオプションであるヘッダは表示されません。
type UAC proxy UAS registrar
_____________________________________________________
Accept R - o m m
Accept-Encoding R - - m m
Accept-Language R - b b b
Allow 405 o - - -
Authorization R a o a a
Call-ID g m m m m
Content-Encoding g m - m m
Content-Length g m m m m
Content-Type g m - m m
CSeq g m m m m
Encryption g e - e e
Expires g - o o m
From g m o m m
Hide R - m - -
Contact R - - - m
Contact r r r - -
Max-Forwards R - b - -
Proxy-Authenticate 407 a - - -
Proxy-Authorization R - a - -
Proxy-Require R - m - -
Require R m - m m
Response-Key R - - e e
Route R - m - -
Timestamp g o o m m
To g m m m m
Unsupported r b b - -
User-Agent g b - b -
Via g m m m m
WWW-Authenticate 401 a - - -
Table 6: Header Field Processing Requirements
表6：ヘッダーフィールド処理要件
B Usage of the Session Description Protocol (SDP)
セッション記述プロトコル（SDP）のBの使用
This section describes the use of the Session Description Protocol (SDP) (RFC 2327 [6]).
このセクションでは、セッション記述プロトコル（SDP）（RFC 2327 [6]）の使用を記載しています。
B.1 Configuring Media Streams
B.1の設定メディアストリーム
The caller and callee align their media descriptions so that the nth media stream ("m=" line) in the caller's session description corresponds to the nth media stream in the callee's description.
発呼者のセッション記述におけるn番目のメディアストリーム（「M =」行）は被呼者の説明において、n番目のメディア・ストリームに対応するように、発呼者と被呼者は、それらのメディア記述を整列させます。
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.
すべてのメディア記述は、エンコーディングにRTPペイロードタイプから「A = rtpmap」マッピングを含むべきです。
This allows easier migration away from static payload
types.
If the callee wants to neither send nor receive a stream offered by the caller, the callee sets the port number of that stream to zero in its media description.
呼び出し先が送信されなかったり、呼び出し側が提供するストリームを受信するためにどちらたい場合は、呼び出し先はそのメディア記述にゼロにそのストリームのポート番号を設定します。
There currently is no other way than port zero for the
callee to refuse a bidirectional stream offered by the
caller. Both caller and callee need to be aware what media
tools are to be started.
For example, assume that the caller Alice has included the following description in her INVITE request. It includes an audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32).
例えば、アリスが彼女の中に以下の記述が含まれている呼び出し側がINVITEリクエストをすることを前提としています。これは、H.261（ペイロードタイプ31）及びMPEG（ペイロードタイプ32）を使用して、オーディオストリーム及び2つの双方向のビデオストリームを含みます。
v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com c=IN IP4 host.anywhere.com m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000
V = 0 0 =アリス2890844526 2890844526 IN IP4 host.anywhere.com C = IN IP4 host.anywhere.com M =オーディオ49170 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ51372 RTP / AVP 31 = rtpmap：31 H261 / 90000 M =ビデオ53000 RTP / AVP 32 = rtpmap：32 MPV / 90000
The callee, Bob, does not want to receive or send the first video stream, so it returns the media description below:
呼び出し先、ボブは、受信または最初のビデオストリームを送信したくないので、以下のメディアの説明を返します。
v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com c=IN IP4 host.example.com m=audio 47920 RTP/AVP 0 1 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000
V = 0 0 =ボブ2890844730 2890844730 IN IP4 host.example.com C = IN IP4 host.example.com M =オーディオ47920 RTP / AVP 0 1 A = rtpmap：0 PCMU / 8000 = rtpmap：1 8000分の1016メートル=ビデオ0 RTP / AVP 31メートル=ビデオ53000 RTP / AVP 32 = rtpmap：32 MPV / 90000
B.2 Setting SDP Values for Unicast
ユニキャスト用のSDP値の設定B.2
If a session description from a caller contains a media stream which is listed as send (receive) only, it means that the caller is only willing to send (receive) this stream, not receive (send). The same is true for the callee.
発呼者からのセッション記述は、送信（受信）のみと表示されているメディアストリームが含まれている場合、それは（送信）受信しません、このストリームを（受信）呼び出し側が送信するだけで喜んでであることを意味します。同じことは、呼び出し先のために真です。
For receive-only and send-or-receive streams, the port number and address in the session description indicate where the media stream should be sent to by the recipient of the session description, either caller or callee. For send-only streams, the address and port number have no significance and SHOULD be set to zero.
以下のための専用受信し、ストリームを受信送信-OR-、セッション記述におけるポート番号とアドレスは、メディアストリームは、セッション記述の受信者、発信者または被呼者のいずれかによって送信されるべき場所を示します。送信専用ストリームの場合、アドレスとポート番号は意味を持ちませんし、ゼロに設定する必要があります。
The list of payload types for each media stream conveys two pieces of information, namely the set of codecs that the caller or callee is capable of sending or receiving, and the RTP payload type numbers used to identify those codecs. For receive-only or send-and-receive media streams, a caller SHOULD list all of the codecs it is capable of supporting in the session description in an INVITE or ACK. For send-only streams, the caller SHOULD indicate only those it wishes to send for this session. For receive-only streams, the payload type numbers indicate the value of the payload type field in RTP packets the caller is expecting to receive for that codec type. For send-only streams, the payload type numbers indicate the value of the payload type field in RTP packets the caller is planning to send for that codec type. For send-and-receive streams, the payload type numbers indicate the value of the payload type field the caller expects to both send and receive.
各メディアストリームのためのペイロードタイプのリストは、二つの情報、すなわち、発呼者又は被呼者が送信または受信することが可能であるコーデックのセット、及びそれらのコーデックを識別するために使用されるRTPペイロードタイプ番号を伝えます。以下の場合のみ、受信またはメディア・ストリームを受信送っ-と-、呼び出し側は、それがINVITEまたはACKのセッション記述でサポート可能なコーデックのすべてをリストする必要があります。送信のみのストリームの場合、呼び出し側は、それがこのセッションのために送りたいものだけを示すべきです。受信専用ストリームのペイロードタイプ番号は、RTPペイロードタイプフィールドの値は、呼び出し元がそのコーデックタイプのために受信するように期待されるパケットを示しています。送信専用ストリームの場合、ペイロードタイプ番号は、RTPペイロードタイプフィールドの値は、呼び出し元がそのコーデックタイプのために送信することを計画しているパケットを示しています。用受信送信・アンド・ストリーム、ペイロードタイプ番号は、ペイロードタイプフィールドの値は、呼び出し元が送信及び受信するために、両方の期待を示しています。
If a media stream is listed as receive-only by the caller, the callee lists, in the response, those codecs it intends to use from among the ones listed in the request. If a media stream is listed as send-only by the caller, the callee lists, in the response, those codecs it is willing to receive among the ones listed in the the request. If the media stream is listed as both send and receive, the callee lists those codecs it is capable of sending or receiving among the ones listed by the caller in the INVITE. The actual payload type numbers in the callee's session description corresponding to a particular codec MUST be the same as the caller's session description.
メディアストリームが受信専用呼び出し側によって、呼び出し先リストを、応答としてリストされている場合、それらのコーデックには、リクエストに記載されているものの中から使用する予定です。メディアストリームが送信専用呼び出し側によって、呼び出し先リストを、応答としてリストされている場合、これらのコーデックは、その要求に記載されているものの間で送受信していく所存です。両方が送受信などのメディアストリームが表示されている場合、呼び出される側は、それが送信またはINVITEに呼び出し側がリストされているものの中から受信することが可能であるこれらのコーデックを示しています。特定のコーデックに対応する被呼者のセッション記述における実際のペイロードタイプ番号は、発信者のセッション記述と同じでなければなりません。
If caller and callee have no media formats in common for a particular stream, the callee MUST return a session description containing the particular "m=" line, but with the port number set to zero, and no payload types listed.
呼び出し元と呼び出し先は、特定のストリームに共通でないメディアフォーマットを持っていない場合、被呼者は、特定の「M =」行を含むセッション記述を返すが、ゼロに設定されたポート番号、および列挙されないペイロードタイプでなければなりません。
If there are no media formats in common for all streams, the callee SHOULD return a 400 response, with a 304 Warning header field.
すべてのストリームに共通にないメディアフォーマットが存在しない場合、被呼側304 Warningヘッダーフィールドと、400応答を返すべきです。
B.3 Multicast Operation
B.3マルチキャスト操作
The interpretation of send-only and receive-only for multicast media sessions differs from that for unicast sessions. For multicast, send-only means that the recipient of the session description (caller or callee) SHOULD only send media streams to the address and port indicated. Receive-only means that the recipient of the session description SHOULD only receive media on the address and port indicated.
ユニキャストセッションのためのものと異なるだけで、送信と受信専用マルチキャストメディアセッションのための解釈。マルチキャストのために、送信専用セッション記述（発呼者または被呼者）の受信者のみが示されたアドレスとポートにメディアストリームを送信しなければならないことを意味します。受信専用セッション記述の受取人だけアドレスとポート上のメディアが示さ受けなければならないことを意味します。
For multicast, receive and send multicast addresses are the same and all parties use the same port numbers to receive media data. If the session description provided by the caller is acceptable to the callee, the callee can choose not to include a session description or MAY echo the description in the response.
マルチキャストの場合は、受信および送信マルチキャストアドレスは同じであり、すべての関係者は、メディアデータを受信するために同じポート番号を使用します。呼び出し側が提供するセッション記述は、呼び出し先に受け入れられる場合は、呼び出し先は、セッション記述を含めるしないことを選択することができたり、応答して説明をエコーするかもしれません。
A callee MAY, in the response, return a session description with some of the payload types removed, or port numbers set to zero (but no other value). This indicates to the caller that the callee does not support the given stream or media types which were removed. A callee MUST NOT change whether a given stream is send-only, receive-only, or send-and-receive.
被呼MAYは、応答して、ゼロに設定除去ペイロードタイプ、またはポート番号の一部とのセッション記述（ただし他の値）を返します。これは、呼び出し先が削除された、指定されたストリームまたはメディアの種類をサポートしていない呼び出し元に示します。呼び出し先は、指定されたストリームは、唯一、送信、受信のみ、または受信送信-と-であるかどうかを変更してはなりません。
If a callee does not support multicast at all, it SHOULD return a 400 status response and include a 330 Warning.
呼び出し先がすべてでマルチキャストをサポートしていない場合は、400のステータス応答を返すと330警告を含むべきです。
B.4 Delayed Media Streams
B.4メディアストリームの遅延
In some cases, a caller may not know the set of media formats which it can support at the time it would like to issue an invitation. This is the case when the caller is actually a gateway to another protocol which performs media format negotiation after call setup. When this occurs, a caller MAY issue an INVITE with a session description that contains no media lines. The callee SHOULD interpret this to mean that the caller wishes to participate in a multimedia session described by the session description, but that the media streams are not yet known. The callee SHOULD return a session description indicating the streams and media formats it is willing to support, however. The caller MAY update the session description either in the ACK request or in a re-INVITE at a later time, once the streams are known.
いくつかのケースでは、呼び出し側は、それはそれは招待状を発行したい時にサポートできるメディアフォーマットのセットを知らないかもしれません。これは、発信者が実際に呼設定の後にメディアフォーマットのネゴシエーションを行う別のプロトコルへのゲートウェイである場合です。これが発生すると、呼び出し側には、メディアラインが含まれていないセッション記述でINVITEを発行することができます。呼び出し先は、呼び出し側がセッション記述で記述マルチメディアセッションに参加したいが、メディアストリームがまだ知られていないことをことを意味するためにこれを解釈すべきです。被呼者は、しかし、サポートしても構わないと思っているストリームおよびメディアフォーマットを示すセッション記述を返すべきです。ストリームが知られた後、発信者は、後の時点でACK要求または再INVITEのいずれかでセッション記述を更新してもよいです。
B.5 Putting Media Streams on Hold
保留メディアストリームを置くB.5
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more media streams, a party re-invites the other by sending an INVITE request with a modified session description. The session description is the same as in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0).
通話中の当事者が「保留」他の当事者、すなわちを入れたい場合は、それが一時的に1つまたは複数のメディアストリームの送信を停止し、党が修正セッション記述でINVITEリクエストを送信することによって、他の再誘うように要求します。セッション記述は、元の招待（または応答）が、「C」先保留されるメディアストリームのためのアドレスはゼロに設定されている（0.0.0.0）と同じです。
B.6 Subject and SDP "s=" Line
B.6件名及びSDP "のS =" ライン
The SDP "s=" line and the SIP Subject header field have different meanings when inviting to a multicast session. The session description line describes the subject of the multicast session, while the SIP Subject header field describes the reason for the invitation. The example in Section 16.2 illustrates this point. For invitations to two-party sessions, the SDP "s=" line MAY be left empty.
マルチキャストセッションに招待するときSDP「のS =」ラインとSIP件名ヘッダフィールドは異なる意味を有します。 SIP件名ヘッダフィールドは、招待の理由を説明しながら、セッション記述ラインは、マルチキャストセッションの主題を記載します。セクション16.2の例では、この点を示しています。二大政党のセッションへの招待については、SDP「のS =」行が空のままになることがあります。
B.7 The SDP "o=" Line
B.7 SDPの "o =" ラインを
The "o=" line is not strictly necessary for two-party sessions, but MUST be present to allow re-use of SDP-based tools.
「O =」行は、厳密に二大政党のセッションのために必要ではないが、SDPベースのツールの再利用を可能にするために存在しなければなりません。
C Summary of Augmented BNF
増補BNFのCの概要
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [9]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
この文書で指定された機構の全ては、RFC 822によって使用されるものと同様の散文と拡張バッカスナウア記法（BNF）[9]の両方に記載されています。実装者はこの仕様を理解するために、表記法に精通している必要があります。増補BNFは、以下の構造が含まれています。
name = definition
名前=定義
The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
ルールの名前は、（任意の封入せず、「<」と「>」）は、単に名前自体と等しい「=」キャラクタによってその定義から分離されます。ホワイトスペースは、継続行のインデントが複数行にわたるルールの定義を示すために使用されている中で唯一重要です。特定の基本的なルールは、アングルブラケットは、その存在がルール名の使用を見分ける容易にするたびに定義内で使用される等SP、LWS、HT、CRLF、DIGIT、ALPHA、として、大文字です。
"literal"
"リテラル"
Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
引用符はリテラルテキストを囲みます。特に明記しない限り、テキストは大文字と小文字を区別しません。
rule1 | rule2
ルール1 |ルール2
Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
バー（「|」）で区切られた要素が代替され、例えば、「はい|いいえ」はい受け入れる、あるいは全くます。
(rule1 rule2)
（ルール1のルール2）
Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
括弧で囲まれた要素は、単一の要素として扱われます。したがって、 "（elemは（FOO |バー）のelem）は、" 可能にトークンシーケンス "elemはfooというのelem" と "elem bar elem"。
*rule
*ルール
The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
要素の前の文字「*」は反復を示します。完全形は素子の少なくとも<N>と高々<M>の発生を示す「<N> * <M>要素」です。 「*（要素）」はゼロを含む任意の数を、可能にするようにデフォルト値は0と無限大です。 「1 *要素」とは、少なくとも1つが必要です。そして「1 *の2element」は1か2を可能にします。
[rule]
[ルール]
Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
角カッコは、オプションの要素を囲みます。 "[FOOバー]は" "* 1（FOOバー）" に相当します。
N rule
Nルール
Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
特定の繰り返し： "<N>（要素）は" "<N> * <N>（要素）" に相当します。つまり、正確に<N>（要素）の発生。したがって2DIGITは、2桁の数字であり、そして3ALPHAはアルファベット3文字の文字列です。
#rule
＃ルール
A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m> element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as
構築物「＃」の要素のリストを定義するために、「*」に似て定義されます。完全形は（「」）それぞれが1つ以上のカンマで区切られた、少なくとも<n>は、ほとんど<M>要素に示す「<N>＃<M>要素」であり、任意の線形空白（LWS）。これは、リストの通常の形は非常に簡単になります。このようなルール
( *LWS element *( *LWS "," *LWS element ))
（* LWS要素*（* LWS "" * LWS要素））
can be shown as 1# element. Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element)" is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
1＃要素として示すことができます。この構築物が使用されている場所、null要素は許可されているが、本要素の数に寄与しません。すなわち、「（要素）、（要素）」許可、2つだけの要素としてカウントされます。少なくとも一つの要素が必要とされるため、少なくとも一つの非ヌル要素が存在しなければなりません。 「#element」はゼロを含む、任意の数のを可能にするようにデフォルト値は0と無限大です。 「1＃要素」とは、少なくとも1つが必要です。そして「1つの＃の2element」は1か2を可能にします。
; comment
;コメント
A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
セミコロンは、ルールテキストの右にある距離をオフに設定し、行の終わりまで続くコメントを開始します。これは仕様に対して有用な注釈をつけるための簡単な方法です。
implied *LWS
暗黙の* LWS
The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent tokens and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
この仕様によって記述文法は、単語ベースです。特記する場合を除いて、線形空白（LWS）は、フィールドの解釈を変えることなく、任意の2つの隣接する単語（トークンまたは引用文字列）の間に、隣接するトークンとセパレータとの間に含めることができます。それらがそうでなければ、単一のトークンとして解釈されるので、少なくとも一つのデリミタ（LWS及び/又はセパレータ）は、任意の2つのトークン（「トークン」は、以下の定義用）の間に存在しなければなりません。
C.1 Basic Rules
C.1基本ルール
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986.
次のルールは、基本的な構文解析構造を記述するために本明細書を通して使用されています。 US-ASCIIコード化文字セットはANSI X3.4-1986で定義されています。
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
alpha = lowalpha | upalpha
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
alphanum = alpha | digit
CTL = <any US-ASCII control character
(octets 0 -- 31) and DEL (127)>
CR = %d13 ; US-ASCII CR, carriage return character
LF = %d10 ; US-ASCII LF, line feed character
SP = %d32 ; US-ASCII SP, space character
HT = %d09 ; US-ASCII HT, horizontal tab character
CRLF = CR LF ; typically the end of a line
The following are defined in RFC 2396 [12] for the SIP URI:
SIP URIのためのRFC 2396 [12]で定義されている次の
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'"
| "(" | ")"
escaped = "%" hex hex
SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
継続行はスペースまたは水平タブで始まる場合、SIPヘッダフィールド値が複数行に折り畳むことができます。折りたたみを含むすべてのリニアホワイトスペースは、SPと同じ意味を持っています。受信者は、フィールドの値を解釈するか、下流のメッセージを転送する前に、単一のSPを持つ任意の線形空白を置き換えることができます。
LWS = [CRLF] 1*( SP | HT ) ; linear whitespace
LWS = [CRLF] 1 *（SP | HT）;リニアの空白
The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 character set (RFC 2279 [21]). In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set.
TEXT-UTF8規則は、メッセージパーサによって解釈されることを意図するものではない記述フィールドの内容と値のために使用されます。 * TEXT-UTF8の言葉はUTF8文字セット（RFC 2279 [21]）から文字が含まれています。この点において、SIPは、ISO 8859-1文字セットを使用してHTTPとは異なります。
TEXT-UTF8 = <any UTF-8 character encoding, except CTLs,
but including LWS>
A CRLF is allowed in the definition of TEXT-UTF8 only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT-UTF8 value.
CRLFだけヘッダーフィールド継続の一部としてTEXT-UTF8の定義で許容されます。折りたたみLWSはTEXT-UTF8値の解釈前に、単一のSPに置き換えされることが期待されます。
Hexadecimal numeric characters are used in several protocol elements.
進数字は、いくつかのプロトコル要素で使用されています。
hex = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | digit
Many SIP header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value.
多くのSIPヘッダフィールド値はLWSまたは特殊文字で区切られた単語から成ります。これらの特殊文字は、パラメータ値内で使用されるように引用符で囲まれた文字列でなければなりません。
token = 1*< any CHAR except CTL's or separators>
separators = "(" | ")" | "<" | ">" | "@" |
"," | ";" | ":" | "\" | <"> |
"/" | "[" | "]" | "?" | "=" |
"{" | "}" | SP | HT
Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
コメントは括弧付きコメントテキストを囲むことにより、いくつかのSIPヘッダフィールドに含めることができます。コメントは自分のフィールド値定義の一部として「コメント」を含むフィールドで許可されています。他のすべてのフィールドでは、括弧はフィールド値の一部とみなされます。
comment = "(" *(ctext | quoted-pair | comment) ")"
ctext = < any TEXT-UTF8 excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using double-quote marks.
それは、二重引用符を使用して引用されている場合は、テキストの文字列は、単一の単語として解析されます。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT-UTF8 except <">>
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
バックスラッシュ文字（「\」）は唯一の引用された文字列とコメント構文内の単一文字引用メカニズムとして使用することができます。
quoted-pair = " \ " CHAR
引用されたペア=「\」CHAR
D Using SRV DNS Records
SRVのDNSレコードを使用してD
The following procedure is experimental and relies on DNS SRV records (RFC 2052 [14]). The steps listed below are used in place of the two steps in section 1.4.2.
以下の手順は、実験で、DNS SRVレコード（RFC 2052 [14]）に依存しています。以下の手順は、セクション1.4.2に2段階の代わりに使用されています。
If a step elicits no addresses, the client continues to the next step. However if a step elicits one or more addresses, but no SIP server at any of those addresses responds, then the client concludes the server is down and doesn't continue on to the next step.
ステップは何のアドレスを誘発しない場合、クライアントは、次のステップに進みます。ステップは、1つ以上のアドレスを誘発が、それらのアドレスのいずれかで、何のSIPサーバが応答しない場合は、クライアントは、サーバーがダウンして、次のステップに進んでいないと結論します。
When SRV records are to be used, the protocol to use when querying for the SRV record is "sip". SRV records contain port numbers for servers, in addition to IP addresses; the client always uses this port number when contacting the SIP server. Otherwise, the port number in the SIP URI is used, if present. If there is no port number in the URI, the default port, 5060, is used.
SRVレコードを使用する場合、SRVレコードを照会するときに使用するプロトコルは、「SIP」です。 SRVレコードは、IPアドレスに加えて、サーバのポート番号が含まれています。 SIPサーバーに接続するとき、クライアントは常にこのポート番号を使用しています。そうでなければ、SIP URIのポート番号が存在する場合、使用されています。 URIにはポート番号が存在しない場合、デフォルトのポート、5060は、使用されています。
1. If the host portion of the Request-URI is an IP address,
the client contacts the server at the given address. If the
host portion of the Request-URI is not an IP address, the
client proceeds to the next step.
2. The Request-URI is examined. If it contains an explicit port number, the next two steps are skipped.
2. Request-URIが検討されています。それが明示的にポート番号が含まれている場合は、次の2つの手順はスキップされます。
3. The Request-URI is examined. If it does not specify a protocol (TCP or UDP), the client queries the name server for SRV records for both UDP (if supported by the client) and TCP (if supported by the client) SIP servers. The format of these queries is defined in RFC 2052 [14]. The results of the query or queries are merged together and ordered based on priority. Then, the searching technique outlined in RFC 2052 [14] is used to select servers in order. If DNS doesn't return any records, the user goes to the last step. Otherwise, the user attempts to contact each server in the order listed. If no server is contacted, the user gives up.
3. Request-URIが検討されています。それは、プロトコル（TCPまたはUDP）を指定しない場合はSIPサーバ（クライアントがサポートしている場合）、クライアントはUDP（クライアントでサポートされている場合）とTCPの両方のためのSRVレコードのネームサーバーを照会します。これらのクエリのフォーマットは、RFC 2052 [14]で定義されています。クエリまたはクエリの結果をマージして、優先度に基づいて順序付けされています。次に、RFC 2052に概説サーチ技術[14]は、順番にサーバを選択するために使用されます。 DNSは、すべてのレコードを返さない場合、ユーザーは、最後のステップに行きます。そうでない場合、ユーザは、リストされているために、各サーバーに接続しようとします。何のサーバに接続されていない場合、ユーザーはあきらめます。
4. If the Request-URI specifies a protocol (TCP or UDP) that is supported by the client, the client queries the name server for SRV records for SIP servers of that protocol type only. If the client does not support the protocol specified in the Request-URI, it gives up. The searching technique outlined in RFC 2052 [14] is used to select servers from the DNS response in order. If DNS doesn't return any records, the user goes to the last step. Otherwise, the user attempts to contact each server in the order listed. If no server is contacted, the user gives up.
4.要求URIがクライアントによってサポートされているプロトコル（TCPまたはUDP）を指定した場合、クライアントはそのプロトコルタイプのSIPサーバのためのSRVレコードのネームサーバーを照会します。クライアントが要求URIで指定されたプロトコルをサポートしていない場合、それはあきらめます。 RFC 2052 [14]に概説サーチ技術は、順にDNS応答からサーバを選択するために使用されます。 DNSは、すべてのレコードを返さない場合、ユーザーは、最後のステップに行きます。そうでない場合、ユーザは、リストされているために、各サーバーに接続しようとします。何のサーバに接続されていない場合、ユーザーはあきらめます。
5. The client queries the name server for address records for the host portion of the Request-URI. If there were no address records, the client stops, as it has been unable to locate a server. By address record, we mean A RR's, AAAA RR's, or their most modern equivalent.
5.クライアントは、Request-URIのホスト部分のためのアドレスレコードのネームサーバーを照会します。何のアドレスレコードが存在しない場合は、サーバーを見つけることができなかったとして、クライアントは、停止します。アドレスレコードによって、我々はRRの、AAAA RRの、または彼らの最も近代的な同等を意味します。
A client MAY cache a successful DNS query result. A successful query is one which contained records in the answer, and a server was contacted at one of the addresses from the answer. When the client wishes to send a request to the same host, it starts the search as if it had just received this answer from the name server. The server uses the procedures specified in RFC1035 [15] regarding cache invalidation when the time-to-live of the DNS result expires. If the client does not find a SIP server among the addresses listed in the cached answer, it starts the search at the beginning of the sequence described above.
クライアントは、成功したDNSクエリの結果をキャッシュすることができます。成功したクエリが答えでレコードを含まれる1つであり、サーバは答えからのアドレスのいずれかで接触させました。クライアントが同じホストに要求を送信したい場合、それは単にネームサーバからこの回答を受けたかのように検索を開始します。生存時間DNS結果の期限が切れると、サーバーは、キャッシュの無効化についてはRFC1035 [15]で指定された手順を使用しています。クライアントがキャッシュされた応答に記載されているアドレスのうち、SIPサーバが見つからない場合は、上記のシーケンスの先頭から検索を開始します。
For example, consider a client that wishes to send a SIP request. The Request-URI for the destination is sip:user@company.com. The client only supports UDP. It would follow these steps:
例えば、SIPリクエストを送信したいクライアントを考えます。 user@company.com：目的地のためのRequest-URIは、SIPです。クライアントは、UDPをサポートしています。これは、次の手順を実行します：
1. The host portion is not an IP address, so the client goes
to step 2 above.
2. The client does a DNS query of QNAME="sip.udp.company.com", QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it omits the TCP query. There were no addresses in the DNS response, so the client goes to the next step.
2.クライアントは、QNAME = "sip.udp.company.com"、QCLASS =では、QTYPE = SRVのDNSクエリを行います。それはTCPをサポートしていないので、それがTCPクエリを省略します。そこDNS応答にはアドレスがなかったので、クライアントは、次のステップに行きます。
3. The client does a DNS query for A records for "company.com". An address is found, so that client attempts to contact a server at that address at port 5060.
3.クライアントは、「company.com」のレコードのDNSクエリを行います。クライアントは、ポート5060でそのアドレスでサーバーに接続しようとするようにアドレスが、発見されました。
E IANA Considerations
E IANAの考慮事項
Section 4.4 describes a name space and mechanism for registering SIP options.
4.4節は、SIPオプションを登録するための名前空間とメカニズムについて説明します。
Section 6.41 describes the name space for registering SIP warn-codes.
セクション6.41は、SIP警告-コードを登録するためのネームスペースを示します。
F Acknowledgments
F謝辞
We wish to thank the members of the IETF MMUSIC WG for their comments and suggestions. Detailed comments were provided by Anders Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe J. Sambol, and Eric Tremblay.
我々は彼らのコメントや提案をIETF MMUSIC WGのメンバーに感謝したいです。詳細なコメントはアンダース・クリステンセン、ジム・ブラー、デイブDevanathan、ヤロンGoland、クリスチャンのHuitema、Gadi氏Karmi、ジョナサン・レノックス、キースムーア、バーン・パクソン、モシェJ. Sambol、そしてエリック・トレンブレイによって提供されました。
This work is based, inter alia, on [37,38].
この作品は、[37,38]に、とりわけ、ベースにしています。
G Authors' Addresses
Gの著者のアドレス
Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) 1947 Center St., Suite 600 Berkeley, CA 94704-119 USA Email: mjh@aciri.org
マーク・ハンドリーAT＆ISCIでインターネットリサーチのためのTセンター（ACIRI）1947センターセント、スイート600バークレー、CA 94704から119 USA電子メール：mjh@aciri.org
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu
コンピュータサイエンスコロンビア大学のヘニングSchulzrinneと学科1214年アムステルダムアベニュー、ニューヨーク、NY 10027 USA Eメール：schulzrinne@cs.columbia.edu
Eve Schooler Computer Science Department 256-80 California Institute of Technology Pasadena, CA 91125 USA Email: schooler@cs.caltech.edu
イブ学生はコンピュータサイエンス学部256から80技術パサデナのカリフォルニア工科大学、CA 91125 USA電子メール：schooler@cs.caltech.edu
Jonathan Rosenberg Lucent Technologies, Bell Laboratories Rm. 4C-526 101 Crawfords Corner Road Holmdel, NJ 07733 USA Email: jdrosen@bell-labs.com
ジョナサン・ローゼンバーグルーセント・テクノロジーズ、ベル研究所Rmを。 4C-526 101 Crawfordsコーナー道路ホルムデル、NJ 07733 USA電子メール：jdrosen@bell-labs.com
H Bibliography
H文献
[1] Pandya, R., "Emerging mobile and personal communication systems," IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995.
[1] Pandya、R.、「モバイルおよびパーソナル通信システムの新興、」IEEEコミュニケーションズマガジン、体積33頁。44--52、1995年6月。
[2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification", RFC 2205, October 1997.
[2]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年10月。
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: a transport protocol for real-time applications", RFC 1889, Internet Engineering Task Force, Jan. 1996.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、インターネットエンジニアリングタスクフォース、1996年1月。
[4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming protocol (RTSP)", RFC 2326, April 1998.
[4] Schulzrinneと、H.、Lanphier、R.及びA.ラオ、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[5] Handley, M., "SAP: Session announcement protocol," Internet Draft, Internet Engineering Task Force, Nov. 1996. Work in progress.
[5]ハンドリー、M.、「SAP：セッション発表プロトコル、」インターネットドラフト、インターネットエンジニアリングタスクフォース、進行中の11月1996年作品。
[6] Handley, M. and V. Jacobson, "SDP: session description protocol", RFC 2327, April 1998.
[6]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[7] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[7]国際電気通信連合、「サービスの非保証品質を提供するローカルエリアネットワークのためのビジュアル電話システムおよび機器、」勧告H.323、ITU、ジュネーブ、スイス、1996年5月の電気通信標準化部門。
[8] International Telecommunication Union, "Control protocol for multimedia communication," Recommendation H.245, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[8]国際電気通信連合、「マルチメディア通信のための制御プロトコル、」勧告H.245、ITU、ジュネーブ、スイス、1998年2月の電気通信標準化部門。
[9] International Telecommunication Union, "Media stream packetization and synchronization on non-guaranteed quality of service LANs," Recommendation H.225.0, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.
[9]国際電気通信連合、「サービスLANの非保証品質上のメディアストリームのパケットとの同期、」勧告H.225.0、ITU、ジュネーブ、スイス、1996年11月の電気通信標準化部門。
[10] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, Mardch 1997.
[10]ブラドナー、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、Mardch 1997。
[11] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC 2068, January 1997.
[11]フィールディング、R.、ゲティス、J.、モーグル、J.、ニールセン、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform resource identifiers (URI): generic syntax", RFC 2396, August 1998.
[12]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource locators (URL)", RFC 1738, December 1994.
[13]バーナーズ - リー、T.、Masinter、L.及びM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[14] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[14] Gulbrandsenの、A.及びP.いるVixie、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2052、1996年10月。
[15] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, Noveberm 1997.
[15] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035 Noveberm 1997。
[16] Hamilton, M. and R. Wright, "Use of DNS aliases for network services", RFC 2219, October 1997.
[16]ハミルトン、M.とR.ライト、 "ネットワークサービスのDNSエイリアスの使用"、RFC 2219、1997年10月。
[17] Zimmerman, D., "The finger user information protocol", RFC 1288, December 1991.
[17]ジマーマン、D.、 "指のユーザー情報プロトコル"、RFC 1288、1991年12月。
[18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC 2167, June 1997.
[18]ウィリアムソン、S.、Kosters、M.、Blacka、D.、シン、J.及びK. Zeilstra、 "紹介WHOIS（rwhois）プロトコルV1.5"、RFC 2167、1997年6月。
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access protocol", RFC 1777, March 1995.
[19]永、W.、ハウズ、T.とS. Kille、 "軽量のディレクトリアクセスプロトコル"、RFC 1777、1995年3月。
[20] Schooler, E., "A multicast user directory service for synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996.
[20]学生は、E.、「同期ランデブーのためのマルチキャストユーザディレクトリサービス、」修士論文CS-TR-96から18、コンピュータサイエンス、カリフォルニア工科大学、パサデナ、カリフォルニア州、1996年8月の教室。
[21] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[21] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[22] Stevens, W., TCP/IP illustrated: the protocols , vol. 1. Reading, Massachusetts: Addison-Wesley, 1994.
[22]スティーブンス、W.、TCP / IPが示さ：プロトコル、容量を。 1.読書、マサチューセッツ州：アディソン・ウェズリー、1994。
[23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[23]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[24] Crocker, D., "Standard for the format of ARPA internet text messages", RFC STD 11, RFC 822, August 1982.
[24]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、RFC STD 11、RFC 822、1982年8月。
[25] Meyer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.
[25]マイヤー、D.、1998年7月、RFC 2365 "管理上のIPマルチキャストスコープ"。
[26] Schulzrinne, H., "RTP profile for audio and video conferences with minimal control", RFC 1890, January 1996
[26] Schulzrinneと、H.、 "最小量のコントロールがあるオーディオとビデオ会議用RTPプロファイル"、RFC 1890、1996年1月
[27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness recommendations for security", RFC 1750, December 1994.
[27]イーストレーク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム推奨"、RFC 1750、1994年12月。
[28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[28]ホフマン、P.、Masinter、L.およびJ. Zawinski、 "mailtoのURLスキーム"、RFC 2368、1998年7月。
[29] Braden, B., "Requirements for internet hosts - application and support", STD 3, RFC 1123, October 1989.
[29]ブレーデン、B.、 "インターネットホストのための要件 - アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[30] Palme, J., "Common internet message headers", RFC 2076, February 1997.
[30]パルメ、J.、 "一般的なインターネットメッセージヘッダ"、RFC 2076、1997年2月。
[31] Alvestrand, H., "IETF policy on character sets and languages", RFC 2277, January 1998.
[31] Alvestrand、H.、 "文字セットと言語のIETF方針"、RFC 2277、1998年1月。
[32] Elkins, M., "MIME security with pretty good privacy (PGP)", RFC 2015, October 1996.
[32]エルキンズ、M.、 "かなり良いプライバシーをMIMEセキュリティ（PGP）"、RFC 2015、1996年10月。
[33] Atkins, D., Stallings, W. and P. Zimmermann, "PGP message exchange formats", RFC 1991, August 1996.
[33]アトキンス、D.、ストーリングス、W.およびP.ツィンマーマン、 "PGPメッセージ交換フォーマット"、RFC 1991、1996年8月。
[34] Atkinson, R., "Security architecture for the internet protocol", RFC 2401, November 1998.
[34]アトキンソン、R.、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 2401、1998年11月。
[35] Allen, C. and T. Dierks, "The TLS protocol version 1.0," RFC 2246, January 1999.
[35]アレン、C.及びT.ダークス、 "TLSプロトコルバージョン1.0、" RFC 2246、1999年1月。
[36] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and digest access authentication," Internet Draft, Internet Engineering Task Force, Sept. 1998. Work in progress.
[36]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.およびL.スチュワート、 "HTTP認証：基本とDigest認証、"インターネットドラフト、インターネットエンジニアリングタスクフォース、進行中の9月1998年作品。
[37] Schooler, E., "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience , vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359.
[37]学生は、E.、「ケーススタディ：パケット交換会議システムにおけるマルチメディア会議制御、」インターネットワーキングのジャーナル：研究と経験、巻。 4頁。99--120、1993年6月ISI転載シリーズISI / RS-93から359まで。
[38] Schulzrinne, H., "Personal mobility for multimedia services in the Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. 1996.
[38]ヨーロッパのワークショップでSchulzrinneと、H.、「インターネットでマルチメディアサービスのためのパーソナルモビリティ、」インタラクティブには、マルチメディアシステム・サービス（IDMS）、（ベルリン、ドイツ）、1996年3月に配布されています。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。