RFC3261 SIP: Session Initiation Protocol 中文版 翻译中
SIP: Session Initiation Protocol
Abstract摘要
This document describes Session Initiation Protocol (SIP),an
application-layer control (signaling) protocol for creating, modifying,
and terminating sessions with one or more participants. These sessions
include Internet telephone calls, multimedia distribution, and multimedia conferences.
本文档描述会话管理协议（SIP），是一个应用层控制（信令）协议。此协议的目的是建立、修改和断开会话。此会话可以包含一个或者多个参与者。这些会话可以是因特网电话会议，多媒体分发和多媒体会议。
SIP invitations used to create sessions carry session descriptions
that allow participants to agree on a set of compatible media types.
SIP makes use of elements called proxy servers to help route requests
to the user's current location, authenticate and authorize users for
services, implement provider call-routing policies, and provide
features to users. SIP also provides a registration function that
allows users to upload their current locations for use by proxy
servers. SIP runs on top of several different transport protocols.
用于发起会话的SIP invitations（发起请求）携带 会话描述session descriptions。 会话描述允许参与者协商一组可兼容得媒体类型。SIP通过Proxy server元素来帮助路由请求至用户的当前位置、 针对服务来鉴权和授权用户、实现呼叫路由策略的提供者和给用户提供features。SIP也提供用户通过proxy servers上传他们目前位置的注册机制。SIP运行在几个不同的传输协议之上。
1 Introduction介绍
There are many applications of the Internet that require the creation
and management of a session, where a session is considered an
exchange of data between an association of participants. The
implementation of these applications is complicated by the practices
of participants: users may move between endpoints, they may be
addressable by multiple names, and they may communicate in several
different media - sometimes simultaneously. Numerous protocols have
been authored that carry various forms of real-time multimedia
session data such as voice, video, or text messages. The Session
Initiation Protocol (SIP) works in concert with these protocols by
enabling Internet endpoints (called user agents) to discover one
another and to agree on a characterization of a session they would
like to share. For locating prospective session participants, and
for other functions, SIP enables the creation of an infrastructure of
network hosts (called proxy servers) to which user agents can send
registrations, invitations to sessions, and other requests. SIP is
an agile, general-purpose tool for creating, modifying, and
terminating sessions that works independently of underlying transport
protocols and without dependency on the type of session that is being
established.
有很多因特网上的应用需要建立和维护会话。会话是指参与者之间协商中数据的交互。参与者的操作使应用的实现变得复杂:用户可能在不同的端点间移动，他们可能通过多个名字被寻址，他们可能通过一些不同的媒体交流--有时同时发生。许多被授权的协议携带着多种实时多媒体会话数据，比如语音，视频或者文本消息。会话发起协议（SIP）通过使因特网节点（被称为用户代代理 user agent）发现彼此和商定他们将共享的会话的特征描述。为了定位未来/潜在的会话参与者，以及其他功能，SIP定义了一个由被称为代理服务（proxy servers）的网络主机组成的框架。通过此框架用户代理可以发送 登记，发起会话等其他请求。SIP是个灵活的、多用途的工具。 它可以建立，修改，断开会话，独立于底层的传输协议，也无关正在建立的会话类型。
2 Overview of SIP Functionality SIP功能概览
SIP is an application-layer control protocol that can establish,
modify, and terminate multimedia sessions (conferences) such as
Internet telephony calls. SIP can also invite participants to
already existing sessions, such as multicast conferences. Media can
be added to (and removed from) an existing session. SIP
transparently supports name mapping and redirection services, which
supports personal mobility [27] users can maintain a single
externally visible identifier regardless of their network location.
SIP是一个应用层控制协议，可以建立、修改和释放类似因特网电话的多媒体会话（会议）。SIP也可以向已经存在的会话添加（invite）参与者，比如多播会议。也可以从一个已存在的会话中添加或删除媒体。SIP透明地支持名称映射和重定向服务。 SIP支持移动性[27]，无论用户处于网络的任何地点，都拥有一个唯一的外部可见表示identifier。
SIP supports five facets of establishing and terminating multimedia
communications:
SIP在如下五方面建立和移除多媒体通信:
User location: determination of the end system to be used for
communication;
User availability: determination of the willingness of the called
party to engage in communications;
User capabilities: determination of the media and media parameters
to be used;
Session setup: "ringing", establishment of session parameters at
both called and calling party;
Session management: including transfer and termination of
sessions, modifying session parameters, and invoking
services.
用户位置:明确用于通信的端系统。
用户可达性:明确被呼叫方放加入通信的意愿。
用户能力:明确使用的媒体和媒体参数。
会话建立:"ringing""振铃"，建立被叫方和寻呼方的会话参数。
会话管理:包括转移、移除会话，修改会话参数，调用服务。
SIP is not a vertically integrated communications system. SIP is
rather a component that can be used with other IETF protocols to
build a complete multimedia architecture. Typically, these
architectures will include protocols such as the Real-time Transport
Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
2326 [29]) for controlling delivery of streaming media, the Media
Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
gateways to the Public Switched Telephone Network (PSTN), and the
Session Description Protocol (SDP) (RFC 2327 [1]) for describing
multimedia sessions. Therefore, SIP should be used in conjunction
with other protocols in order to provide complete services to the
users. However, the SIPbasic functionality and operation of SIP does
not depend on any of these protocols.
SIP不是一个垂直整合的系统。SIP更像是一个组件，被用来和其他IEFT协议一起构建一个完整的多媒体架构。这些框架中包含的代表性协议有如下：用于传输实时数据并提供QOS反馈的实时传输协议（RTP）(RFC 1889 [28])，控制流媒体传送的实时流协议(RTSP) (RFC2326 [29])，控制公共电话交换网络（PSTN）的媒体网关控制协议(MEGACO) (RFC 3015 [30])，以及描述多媒体会话的会话描述协议（SDP)(RFC 2327[1])。所以为了提供给用户完整的服务，SIP协议需要和其他协议结合在一起使用。但是SIP中的基本功能和操作不依赖于这些协议中的任何一个。
SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services.
SIP不提供服务。相反地，SIP提供用于实现不同服务的基本构件（primitives ）。比如，SIP可以定位一个用户，传送一个不透明的对象至其目前位置。如果这个基本构件用于传递一个用SDP协议构成的会话描述，以此为例，端点可以商定会话参数。如果和会话描述一样，这同样的基本构件用于传送呼叫者的图片，一个“caller ID”服务可以被容易的实现。像这个例子显示的，一个单独的基本构建通常用于提供一些不同的服务。
SIP does not offer conference control services such as floor control
or voting and does not prescribe how a conference is to be managed.
SIP can be used to initiate a session that uses some other conference
control protocol. Since SIP messages and the sessions they establish
can pass through entirely different networks, SIP cannot, and does
not, provide any kind of network resource reservation capabilities.
SIP不提供会议管理服务，比如floor control，voting，也不规定如何管理一个会议。SIP用于发起一个被其他会议控制协议使用的会话。由于SIP消息和它们建立的会话可以完整地通过不同的网络传递。SIP不能，也不会提供任何网络资源保留/预定能力。
The nature of the services provided make security particularly
important. To that end, SIP provides a suite of security services,
which include denial-of-service prevention, authentication (both user
to user and proxy to user), integrity protection, and encryption and
privacy services.
提供的服务的特性，让安全特别重要。为此目的，SIP提供了一组安全服务，包括服务拒绝防范，用户间和代理与用户间的鉴权， 完整性保护，加密和私有服务。
SIP works with both IPv4 and IPv6.
SIP可以用IPV4和IPV6。
3 Terminology术语
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
"MUST"必须, "MUST NOT"必须不, "REQUIRED"要求, "SHALL"应当, "SHALL NOT"应当不,
"SHOULD"应该, "SHOULD NOT"应该不, "RECOMMENDED"建议, "NOT RECOMMENDED"不建议, "MAY"可以, and "OPTIONAL"可选的。
4 Overview of Operation操作概览
This section introduces the basic operations of SIP using simple examples.
This section is tutorial in nature and does not contain any normative
The first example shows the basic functions of SIP: location of an
end point, signal of a desire to communicate, negotiation of session
parameters to establish the session, and teardown of the session once
established.
本节通过简单的例子介绍SIP的基本操作。本节是一个自然语言描述的指导，不包含任何本规范中的状态机制。第一个例子论述SIP的基本操作:一个端点的定位，通信需求的传输，建立会话的会话参数协商，曾经建立的会话的关闭。
Figure 1 shows a typical example of a SIP message exchange between
two users, Alice and Bob. (Each message is labeled with the letter
"F" and a number for reference by the text.) In this example, Alice
uses a SIP application on her PC (referred to as a softphone) to call
Bob on his SIP phone over the Internet. Also shown are two SIP proxy
servers that act on behalf of Alice and Bob to facilitate the session
establishment. This typical arrangement is often referred to as the
"SIP trapezoid" as shown by the geometric shape of the dotted lines
in Figure 1.
图一说明了一个典型例子---两个用户，Alic和Bob键的SIP消息交换。（每一个消息通过字母“F”和一个数字来标注，用于文本中引用）。在这个例子中，Alice通过一个在她电脑上的SIP应用（称之为softphone）经由因特网去呼叫上一个SIP Phone上的BOB。 如图所示，两个SIP代理服务端代表Alice和Bob促成了会话的建立。 根据图一中虚线所构成的几何形状，这个典型的序列经常被称为“SIP 梯形”。
Alice "calls" Bob using his SIP identity, a type of Uniform Resource
Identifier (URI) called a SIP URI. SIP URIs are defined in Section
19.1. It has a similar form to an email address, typically
containing a username and a host name. In this case, it is
sip:[email protected], where biloxi.com is the domain of Bob's SIP
service provider. Alice has a SIP URI of sip:[email protected].
Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
or an entry in an address book. SIP also provides a secure URI,
called a SIPS URI. An example would be sips:[email protected]. A call
made to a SIPS URI guarantees that secure, encrypted transport
(namely TLS) is used to carry all SIP messages from the caller to the
domain of the callee. From there, the request is sent securely to
the callee, but with security mechanisms that depend on the policy of
the domain of the callee.
Alice通过Bob的SIP标识“呼叫”BOB。SIP标识是Uniform Resource Identifier (URI)的一种，称之为SIP URI。 SIP URI在19.1节定义。它和邮件地址的组成类似，通常包含一个用户名和一个host名。在本例中，它是sip:[email protected]。 biloxi.com是Bob的SIP服务提供方的域名。Alice的SIP URI是sip:[email protected]。Alice可以键入Bob的 URI，或者点击一个链接或者地址本的一项。SIP同时提供一个被称为SIPS URI的安全URI。比如可以是 sips:[email protected]. 呼叫SIPS URI可以确保所有的从呼叫方到被叫方域的SIP 消息都使用安全加密的传输（即TLS）。
SIP is based on an HTTP-like request/response transaction model.
Each transaction consists of a request that invokes a particular
method, or function, on the server and at least one response. In
this example, the transaction begins with Alice's softphone sending
an INVITE request addressed to Bob's SIP URI. INVITE is an example
of a SIP method that specifies the action that the requestor (Alice)
wants the server (Bob) to take. The INVITE request contains a number
of header fields. Header fields are named attributes that provide
additional information about a message. The ones present in an
INVITE include a unique identifier for the call, the destination
address, Alice's address, and information about the type of session
that Alice wishes to establish with Bob. The INVITE (message F1 in
Figure 1) might look like this:
SIP建立在类似HTTP协议的请求/响应交互模型之上。每一个交互包含一个请求，和至少一个响应。此请求会触发服务端特定的方法或者函数。在本例中，交互发起于Alice的softphone发送的一个INVITE请求。此INVITE请求指向Bob的SIP URI。INVITE是一个SIP方法的例子。一个SIP方法指定了请求方（Alice）希望服务方（Bob）采取的行动。此INVITE请求包含许多头域。头域被称为属性。属性提供了一个消息的附加信息。在INVITE消息中出现的头域包含：通话的唯一表示，目的地址，Alice的地址，Alice希望和Bob建立的会话类型相关信息。
INVITE消息可能有如下内容（图1中的消息F1）：
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob
From: Alice
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
（Alice的SDP没有显示在这里）
The first line of the text-encoded message contains the method name
(INVITE). The lines that follow are a list of header fields. This
example contains a minimum required set. The header fields are
briefly described below:
此文字编码消息的第一行包含方法名（INVITE）。在第一行后面跟着一组头域。本例包含了最小所需集合。这个头域简单描述如下:
Via contains the address (pc33.atlanta.com) at which Alice is
expecting to receive responses to this request. It also contains a
branch parameter that identifies this transaction.
Via 包含Alice希望接 此请求的响应返回时， 接收响应的地址（pc33.atlanta.com）。它同时包含了标识此交互的分支（branch）参数。
To contains a display name (Bob) and a SIP or SIPS URI
(sip:[email protected]) towards which the request was originally
directed. Display names are described in RFC 2822 [3].
To 包含了 display name（显示姓名） (Bob) 和一个SIP或者SIPS URI(sip:[email protected]).TO指定了请求的原始指向。display name在RFC2822（email格式）中定义。
From also contains a display name (Alice) and a SIP or SIPS URI
(sip:[email protected]) that indicate the originator of the request.
This header field also has a tag parameter containing a random string
(1928301774) that was added to the URI by the softphone. It is used
for identification purposes.
From 包含display name (Alice)和SIP或SIPS URI(sip:[email protected]).它表示了请求的发送方。这个头域也包含一个tag 参数。此tag参数包含softephone添加到URI的一个随机字符串 (1928301774)。此参数也是用于标识目的。
Call-ID contains a globally unique identifier for this call,
generated by the combination of a random string and the softphone's
host name or IP address. The combination of the To tag, From tag,
and Call-ID completely defines a peer-to-peer SIP relationship
between Alice and Bob and is referred to as a dialog.
Call-ID 包含此通话全局唯一的标识。此表示由一个随机字符串和softphone的主机名或IP地址构成。To tag，From tag，和Call-ID完整的定义一个Alice和BOB之间的端到端P2P的SIP关系。此关系被称为dialog。
CSeq or Command Sequence contains an integer and a method name. The
CSeq number is incremented for each new request within a dialog and
is a traditional sequence number.
CSeq或Command Sequence包含一个整数和方法名。在一个dialog里，每一个新请求的CSeq编号都会增加，是一个传统序列号。
Contact contains a SIP or SIPS URI that represents a direct route to
contact Alice, usually composed of a username at a fully qualified
domain name (FQDN). While an FQDN is preferred, many end systems do
not have registered domain names, so IP addresses are permitted.
While the Via header field tells other elements where to send the
response, the Contact header field tells other elements where to send
future requests.
Contact包含一个SIP或SIPS URI，表示联系Alice的一个直接路由，通常是一个全限定域名（fully qualified domain name）（FQDN）格式的用户名.虽然更建议使用FQDN，但由于许多端系统没有注册域名，所以IP地址也是允许的。Via头域用于告知其他元素响应发往哪儿，Contact头域用于告知其他元素未来的请求发往哪儿。
Max-Forwards serves to limit the number of hops a request can make on
the way to its destination. It consists of an integer that is
decremented by one at each hop.
Max-Forwards用于限制一个请求发往目的地的跳数。它包含一个整数，每经过一跳就被减1.
Content-Type contains a description of the message body (not shown).
Content-Type包含消息体的描述（图中没有显示）。
Content-Length contains an octet (byte) count of the message body.Content-Length包含消息体的octet（字节）数。
The complete set of SIP header fields is defined in Section 20.
SIP头域的完整集合定义在20节。
The details of the session, such as the type of media, codec, or
sampling rate, are not described using SIP. Rather, the body of a
SIP message contains a description of the session, encoded in some
other protocol format. One such format is the Session Description
Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the
example) is carried by the SIP message in a way that is analogous to
a document attachment being carried by an email message, or a web
page being carried in an HTTP message.
会话的细节，比如媒体，编码或者抽样率，不会用SIP协议描述。SIP消息体并没有包含会话的描述，这些描述被编码在其他协议格式中。其中一个格式是会话描述协议（Session Description Protocol）（SDP）(RFC 2327 [1]).SIP消息携带SDP消息（本例中没有论述）的方式类似于电子邮件消息携带文档附件，或者HTTP消息中携带网页。
Since the softphone does not know the location of Bob or the SIP
server in the biloxi.com domain, the softphone sends the INVITE to
the SIP server that serves Alice's domain, atlanta.com. The address
of the atlanta.com SIP server could have been configured in Alice's
softphone, or it could have been discovered by DHCP, for example.
因为softphone不知道Bob或者在biloxi.com域的SIP服务器的位置，softphone发送INVITE消息至Alice所属域的SIP服务器atlanta.com。atlanta.com SIP服务器的地址可能已经配置在Alice的softphone上，或者通过DHCP服务发现。
The atlanta.com SIP server is a type of SIP server known as a proxy
server. A proxy server receives SIP requests and forwards them on
behalf of the requestor. In this example, the proxy server receives
the INVITE request and sends a 100 (Trying) response back to Alice's
softphone. The 100 (Trying) response indicates that the INVITE has
been received and that the proxy is working on her behalf to route
the INVITE to the destination. Responses in SIP use a three-digit
code followed by a descriptive phrase. This response contains the
same To, From, Call-ID, CSeq and branch parameter in the Via as the
INVITE, which allows Alice's softphone to correlate this response to
the sent INVITE. The atlanta.com proxy server locates the proxy
server at biloxi.com, possibly by performing a particular type of DNS
(Domain Name Service) lookup to find the SIP server that serves the
biloxi.com domain. This is described in [4]. As a result, it
obtains the IP address of the biloxi.com proxy server and forwards,
or proxies, the INVITE request there. Before forwarding the request,
the atlanta.com proxy server adds an additional Via header field
value that contains its own address (the INVITE already contains
Alice's address in the first Via). The biloxi.com proxy server
receives the INVITE and responds with a 100 (Trying) response back to
the atlanta.com proxy server to indicate that it has received the
INVITE and is processing the request. The proxy server consults a
database, generically called a location service, that contains the
current IP address of Bob. (We shall see in the next section how
this database can be populated.) The biloxi.com proxy server adds
another Via header field value with its own address to the INVITE and
proxies it to Bob's SIP phone.
atlanta.com SIP服务器是SIP服务器的一种，称之为代理服务器。代理服务器接收请求，并为请求方转发请求。并发送100 (Trying) 响应至Alice的softphone。100 (Trying) 响应表示代理已经接收到INVITE并代替她将INVITE路由至目的地。SIP中响应使用三位数字编码，紧跟着一个描述性短语。和INVITE一样，响应也包含TO，From，Call-ID，CSeq和Via中的branch 参数。atlanta.com代理服务器定位到biloxi.com中的代理服务器。定位可能可能是通过特定类型的DNS(Domain Name Service)查询去定位为 biloxi.com域服务的 SIP服务。此过程在【4】中论述。结果，它得到了biloxi.com代理服务的IP地址，转发INVITE请求到那里。在转发请求之前，atlanta.com代理服务添加格外的Via 头域值，包含它自己的地址（INVITE已经将ALice地址作为第一个Via）。 biloxi.com 代理服务接收到INVITE，返回一个 100 (Trying) 响应给atlanta.com代理服务，表示他已经收到INVITE消息，正在处理这个请求。代理服务查询数据库，通常是调用一个包含Bob目前Ip地址的位置服务。（在下一届将要看到如何填充这个数据库。）biloxi.com代理服务向INVITE添加另一个包含它自己地址的Via头域，并转发请求至BOb的SIP phone。
Bob's SIP phone receives the INVITE and alerts Bob to the incoming
call from Alice so that Bob can decide whether to answer the call,
that is, Bob's phone rings. Bob's SIP phone indicates this in a 180
(Ringing) response, which is routed back through the two proxies in
the reverse direction. Each proxy uses the Via header field to
determine where to send the response and removes its own address from
the top. As a result, although DNS and location service lookups were
required to route the initial INVITE, the 180 (Ringing) response can
be returned to the caller without lookups or without state being
maintained in the proxies. This also has the desirable property that
each proxy that sees the INVITE will also see all responses to the
INVITE.
Bob的SIP phone收到INVITE，并通知Bob有来字Alice的来电，以便Bob可以决定是否应答这个通话，即Bob的phone响铃。Bob的SIp phone将上述操作通过180(Ringing)响应告知。此响应通过反方向经由两个代理路由回去。每一个代理根据VIa头域决定是否发送响应和从via头域的顶部移除自己的地址。所以，虽然在路由最初的INVITE是需要DNS和位置发现服务，180 (Ringing)响应返回给发送方时不需要查找，也不需要在代理中维护状态。这也是一个令人满意的特性----每一个看到INVITE的代理都可以看到INVITE的所有响应。
When Alice's softphone receives the 180 (Ringing) response, it passes
this information to Alice, perhaps using an audio ringback tone or by
displaying a message on Alice's screen.
当ALIce的softephone收到 180 (Ringing) 响应，它通过语音回铃音或者显示一个信息到Alice的显示屏上，将这个消息传递给Alice。
In this example, Bob decides to answer the call. When he picks up
the handset, his SIP phone sends a 200 (OK) response to indicate that
the call has been answered. The 200 (OK) contains a message body
with the SDP media description of the type of session that Bob is
willing to establish with Alice. As a result, there is a two-phase
exchange of SDP messages: Alice sent one to Bob, and Bob sent one
back to Alice. This two-phase exchange provides basic negotiation
capabilities and is based on a simple offer/answer model of SDP
exchange. If Bob did not wish to answer the call or was busy on
another call, an error response would have been sent instead of the
200 (OK), which would have resulted in no media session being
established. The complete list of SIP response codes is in Section
21. The 200 (OK) (message F9 in Figure 1) might look like this as
Bob sends it out:
在本例中，Bob决定应答通话。当他摘机，他的SIP phone发送一个200（OK）响应，表示这个通话已经被应答。200 (OK)包含一个携带SDP媒体描述和Bob希望和Alice建立的会话类型的消息体。因此，SDP消息的交换有两个阶段：Alice发给Bob一个，Bot发回给Alice一个。这个两段交换提供了基本的协商能力，它建立在SDP交换的简单的提供/应答模型之上。如果Bob不希望应答这个通话，或者正在忙于另一个通话，一个错误响应会替代200(OK)发送，这将导致没有媒体会话建立。完整的SIP响应编码在21节。Bob发出的200 (OK)（图1中F9消息）可能是如下这样:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob
From: Alice
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
(Bob的SDP没有显示)
The first line of the response contains the response code (200) and
the reason phrase (OK). The remaining lines contain header fields.
The Via, To, From, Call-ID, and CSeq header fields are copied from
the INVITE request. (There are three Via header field values - one
added by Alice's SIP phone, one added by the atlanta.com proxy, and
one added by the biloxi.com proxy.) Bob's SIP phone has added a tag
parameter to the To header field. This tag will be incorporated by
both endpoints into the dialog and will be included in all future
requests and responses in this call. The Contact header field
contains a URI at which Bob can be directly reached at his SIP phone.
The Content-Type and Content-Length refer to the message body (not
shown) that contains Bob's SDP media information.
响应的第一行包含response code响应码（200）和reason phrase原因短语（OK）。后面的其他行包含头部域。Via,To,From,Call-ID和CSeq头域从INVITE请求拷贝。（有三个Via头域值，一个是Alice的SIP phone添加，一个是atlanta.com 代理添加，一个是biloxi.com代理添加。）Bob的SIP phone添加了一个tag 参数至To头域。这个tag将被双方端点合并至这个dialog，将会包含到这个通话将来所有的请求和响应中。Contact头域包含一个URI，通过此URI可以直达在Bob SIP phone上的Bob。涉及到消息体的Content-Type和Content-Length（没有显示出来）包含Bob的SDP媒体信息。
In addition to DNS and location service lookups shown in this
example, proxy servers can make flexible "routing decisions" to
decide where to send a request. For example, if Bob's SIP phone
returned a 486 (Busy Here) response, the biloxi.com proxy server
could proxy the INVITE to Bob's voicemail server. A proxy server can
also send an INVITE to a number of locations at the same time. This
type of parallel search is known as forking.
除了本例中的DNS和位置服务查找，代理服务可以使用灵活的“路由判决”，以决定请求发往哪里。比如，如果Bob的SIP phone返回一个486 (Busy Here) 响应，biloxi.com代理服务可以将IVITE代理至Bob的语音邮箱服务。一个代理服务也可以将INVITE同时发送到一组位置。此种并行查找被称之为forking（分发）。
In this case, the 200 (OK) is routed back through the two proxies and
is received by Alice's softphone, which then stops the ringback tone
and indicates that the call has been answered. Finally, Alice's
softphone sends an acknowledgement message, ACK, to Bob's SIP phone
to confirm the reception of the final response (200 (OK)). In this
example, the ACK is sent directly from Alice's softphone to Bob's SIP
phone, bypassing the two proxies. This occurs because the endpoints
have learned each other's address from the Contact header fields
through the INVITE/200 (OK) exchange, which was not known when the
initial INVITE was sent. The lookups performed by the two proxies
are no longer needed, so the proxies drop out of the call flow. This
completes the INVITE/200/ACK three-way handshake used to establish
SIP sessions. Full details on session setup are in Section 13.
在这个例子中，在两个代理之间，200 (OK)被路由回来，并被Alice的softphone收到。这将导致回铃音停止，表示通话已经被应答。最终，Alice的softphone发送一个确认消息，ACK，到Bob的SIPphone，为了确认最终的响应response (200 (OK))已经收到。本例中Alice的softphone绕过两个代理，直接将ACK发送给Bob的SIP phone。这是因为端点之间通过INVITE/200 (OK)交互中的Contact头域，已经得到了对方了地址（这些在INVITE一开始发送时还不知道）。由于不再需要两个代理执行查找操作，所以后面的通话流程中不需要代理了。上述过程完成了INVITE/200/ACK三次握手，以建立SIP会话。会话建立的完整细节在13节中论述。
Alice and Bob's media session has now begun, and they send media
packets using the format to which they agreed in the exchange of SDP.
In general, the end-to-end media packets take a different path from
the SIP signaling messages.
Alice和Bob的媒体会话现在开始了。他们使用在SDP交互中协商的格式发送媒体包。通常，端对端的媒体流走的路径不同于SIP信令。
During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
sending a re-INVITE containing a new media description. This re-
INVITE references the existing dialog so that the other party knows
that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
The requestor responds to the 200 (OK) with an ACK. If the other
party does not accept the change, he sends an error response such as
488 (Not Acceptable Here), which also receives an ACK. However, the
failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics. Full details on session modification are in Section
14.
在会话中，ALice或者BOb可以决定去修改媒体会话的参数。这一点可以通过发送一个包含新的媒体描述的re-INVITE做到。re-INVITE指向原有的dialog，所以另一方知道去修改哪一个已有的的会话，而不是建立一个新会话。另一个方会发送200 (OK)接受修改。请求方通过ACK回复200 (OK)。如果对方不同意修改，会发送一个类似 488 (Not Acceptable Here)的错误响应，这个错误响应也会得到ACK应答。不过，re-INVITE失败不会导致原有通话失败，原有会话继续使用之前协商的参数。会话修改的细节在14节中论述。
At the end of the call, Bob disconnects (hangs up) first and
generates a BYE message. This BYE is routed directly to Alice's
softphone, again bypassing the proxies. Alice confirms receipt of
the BYE with a 200 (OK) response, which terminates the session and
the BYE transaction. No ACK is sent - an ACK is only sent in
response to a response to an INVITE request. The reasons for this
special handling for INVITE will be discussed later, but relate to
the reliability mechanisms in SIP, the length of time it can take for
a ringing phone to be answered, and forking. For this reason,
request handling in SIP is often classified as either INVITE or non-
INVITE, referring to all other methods besides INVITE. Full details
on session termination are in Section 15.
通话结束时，Bob先关闭（挂断 hangs up）并生成BYE消息。BYE直接路由至Alice的softphone，再一次绕过代理。Alice用200 (OK)响应确认收到BYE。200 (OK)响应关闭会话和BYE事务。不会发送ACK--ACK的发送只用于响应INVITE请求的响应。INVITE特殊处理的原因后面将会讨论，这涉及到SIP的可靠性机制，振铃phone应答的时间和forking。因此，SIP中请求的处理经常分类为INVITE或非INVITE(指除了INVITE之外的所有操作)。会话关闭将在15节详细论述。
Section 24.2 describes the messages shown in Figure 1 in full.
24.2节会完整论述图1中的消息。
In some cases, it may be useful for proxies in the SIP signaling path
to see all the messaging between the endpoints for the duration of
the session. For example, if the biloxi.com proxy server wished to
remain in the SIP messaging path beyond the initial INVITE, it would
add to the INVITE a required routing header field known as Record-
Route that contained a URI resolving to the hostname or IP address of
the proxy. This information would be received by both Bob's SIP
phone and (due to the Record-Route header field being passed back in
the 200 (OK)) Alice's softphone and stored for the duration of the
dialog. The biloxi.com proxy server would then receive and proxy the
ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently
decide to receive subsequent messages, and those messages will pass
through all proxies that elect to receive it. This capability is
frequently used for proxies that are providing mid-call features.
某些情况下，看到会话周期中端点之间所有的消息对SIP信令流路径中的代理是有用的。比如，如果biloxi.com代理希望在触发INVITE后保留在SIP消息路径中，它可以给INVITE添加一个被称为 Record-Route的路由routing头域。此头域包含一个指向代理的主机名或者IP地址的URI。这个信息会被Bob的SIp phone和（因为Record-Route头域在传回的200（OK）中）ALice的softphone收到，会在dialog生存期中保留。 biloxi.com 代理接着就会收到和转发ACK, BYE，以及回复BYE的200(OK)。每个代理可以独立决定是否接收后续的消息。这些消息将传给所有决定接收他们的代理。这个能力经常被用于提供mid-call特性的代理。
Registration is another common operation in SIP. Registration is one
way that the biloxi.com server can learn the current location of Bob.
Upon initialization, and at periodic intervals, Bob's SIP phone sends
REGISTER messages to a server in the biloxi.com domain known as a SIP
registrar. The REGISTER messages associate Bob's SIP or SIPS URI
(sip:[email protected]) with the machine into which he is currently
logged (conveyed as a SIP or SIPS URI in the Contact header field).
The registrar writes this association, also called a binding, to a
database, called the location service, where it can be used by the
proxy in the biloxi.com domain. Often, a registrar server for a
domain is co-located with the proxy for that domain. It is an
important concept that the distinction between types of SIP servers
is logical, not physical.
Registration是SIP中另一个通用操作。Registration是 biloxi.com 服务获取Bob当前位置的一个方式。当初始化后，BOb的SIPphone会以特定间隔发送REGISTER消息到biloxi.com 域上一个被称为SIP registrar的服务。REGISTER消息将将Bob的SIP或SIPS URI (sip:[email protected])和他当前登录的机器（转换为一个在Contact头域中的SIP或SIPS URI）关联起来。registrar将此关系，或者说绑定，写到被称为位置服务的数据库。此数据库可以被biloxi.com域中的代理使用。通常，一个域的registrar服务经常和这个域的代理 地址相同。registrar服务是一个区分SIP服务类型的重要逻辑概念，而非物理概念.
Bob is not limited to registering from a single device. For example,
both his SIP phone at home and the one in the office could send
registrations. This information is stored together in the location
service and allows a proxy to perform various types of searches to
locate Bob. Similarly, more than one user can be registered on a
single device at the same time.
Bob的注册不限于一个单独设备。比如，他家里和公司的的SIP phones都可以发送注册。这个信息被一起保存在位置服务，并允许代理操作不同的查询去定位Bob。类似，可以多个用户同时注册到同一个设备。
The location service is just an abstract concept. It generally
contains information that allows a proxy to input a URI and receive a
set of zero or more URIs that tell the proxy where to send the
request. Registrations are one way to create this information, but
not the only way. Arbitrary mapping functions can be configured at
the discretion of the administrator.
位置服务知识一个抽象概念。通常保存一些信息，允许代理通过输入一个URI并得到 告知代理将请求发往哪儿的一组零个或多个URI。注册是一种建立这些信息的方式，但是不是唯一方式。管理员可以自行配置任何映射函数。
Finally, it is important to note that in SIP, registration is used
for routing incoming SIP requests and has no role in authorizing
outgoing requests. Authorization and authentication are handled in
SIP either on a request-by-request basis with a challenge/response
mechanism, or by using a lower layer scheme as discussed in Section
26.
最后，有一点很重要，在SIP中，注册只是用于路由收到的SIP请求，不用于授权发出的请求。在SIP中，授权和认证要么建立在 challenge/response机制上的request-by-request流程，或者使用在26节中讨论的底层体系。
The complete set of SIP message details for this registration example
is in Section 24.1.
针对注册例子，相关SIP消息细节的完整集合在24.1节中。
Additional operations in SIP, such as querying for the capabilities
of a SIP server or client using OPTIONS, or canceling a pending
request using CANCEL, will be introduced in later sections.
SIP中的其他操作，比如查询SIP服务或者client使用OPTIONS的能力，或者使用CANCEL撤销一个pending的请求，将会在后面章节中介绍。
5 Structure of the Protocol 协议体系
SIP is structured as a layered protocol, which means that its
behavior is described in terms of a set of fairly independent
processing stages with only a loose coupling between each stage. The
protocol behavior is described as layers for the purpose of
presentation, allowing the description of functions common across
elements in a single section. It does not dictate an implementation
in any way. When we say that an element "contains" a layer, we mean
it is compliant to the set of rules defined by that layer.
SIP是一个分层协议。这意味着，其通过一组相当独立的操作阶段描述行为。每个阶段之间都是松耦合的。在一个单独章节中，分层描述的协议行为允许函数的描述 跨元素共享。它不限制任何方式的实现。当我们说一个元素“包含”一层，我们是指他遵守那层定义的一组行为。
Not every element specified by the protocol contains every layer.
Furthermore, the elements specified by SIP are logical elements, not
physical ones. A physical realization can choose to act as different
logical elements, perhaps even on a transaction-by-transaction basis.
不是协议定义的每个元素都包含每一层。进一步说，SIP定义的元素是逻辑元素，不是物理的。一个物理实现可以选择按照不同的逻辑元素操作，可能甚至建立在transaction-by-transaction基础上。
The lowest layer of SIP is its syntax and encoding. Its encoding is
specified using an augmented Backus-Naur Form grammar (BNF). The
complete BNF is specified in Section 25; an overview of a SIP
message's structure can be found in Section 7.
SIP的最底层是他的语法和编码层。编码使用 扩张巴科斯范式augmented Backus-Naur Form grammar (BNF)定义。完整的BNF定义在25节。SIP消息结构的概述在第7节中可以找到。
The second layer is the transport layer. It defines how a client
sends requests and receives responses and how a server receives
requests and sends responses over the network. All SIP elements
contain a transport layer. The transport layer is described in
Section 18.
第二层是传输层。它定义了通过网络，一个客户端如何发送请求和接收响应，以及一个服务端如何接收请求、发送响应。所有的SIP元素都包含传输层。传输层定义在18节。
The third layer is the transaction layer. Transactions are a
fundamental component of SIP. A transaction is a request sent by a
client transaction (using the transport layer) to a server
transaction, along with all responses to that request sent from the
server transaction back to the client. The transaction layer handles
application-layer retransmissions, matching of responses to requests,
and application-layer timeouts. Any task that a user agent client
(UAC) accomplishes takes place using a series of transactions.
Discussion of transactions can be found in Section 17. User agents
contain a transaction layer, as do stateful proxies. Stateless
proxies do not contain a transaction layer. The transaction layer
has a client component (referred to as a client transaction) and a
server component (referred to as a server transaction), each of which
are represented by a finite state machine that is constructed to
process a particular request.
第三层是事务层。Transactions 是SIP中的基本组件。一个事务是一个从client事务（使用传输层）发送的一个至server事务的请求，伴随着所有从server事务发回给client的所有针对那个请求的响应。事务层处理应用层重传，匹配响应到请求和应用层超时。User agent client(用户代理客户端UAC)的任何任务都由一系列事务构成。事务在17节中论述。用户代理（UA）包含事务层，状态代理也是如此。无状态代理不包含事务层。事务层包含一个客户组件（client事务中提及）和一个服务组件（server事务中论述）。这两种组件都包含一个处理特定请求的有限状态机。
The layer above the transaction layer is called the transaction user
(TU). Each of the SIP entities, except the stateless proxy, is a
transaction user. When a TU wishes to send a request, it creates a
client transaction instance and passes it the request along with the
destination IP address, port, and transport to which to send the
request. A TU that creates a client transaction can also cancel it.
When a client cancels a transaction, it requests that the server stop
further processing, revert to the state that existed before the
transaction was initiated, and generate a specific error response to
that transaction. This is done with a CANCEL request, which
constitutes its own transaction, but references the transaction to be
cancelled (Section 9).
事务层之上一层被称为事务用户（transaction user TU）。每一个SIP实体，除了无状态代理，都是一个TU。当一个TU希望发送一个请求，会建立一个客户事务实例。并将请求，及其目的IP地址，端口，运输传给此实例。此实例发送请求。建立client事务的TU，也可以撤销事务。当一个client撤销事务，会请求server停止进一步处理，回滚状态到此事务发起之前的状态。这个操作通过CANCEL请求实现。CANCEL请求也包含它自身的事务，但同时引用将要撤销的事务。
The SIP elements, that is, user agent clients and servers, stateless
and stateful proxies and registrars, contain a core that
distinguishes them from each other. Cores, except for the stateless
proxy, are transaction users. While the behavior of the UAC and UAS
cores depends on the method, there are some common rules for all
methods (Section 8). For a UAC, these rules govern the construction
of a request; for a UAS, they govern the processing of a request and
generating a response. Since registrations play an important role in
SIP, a UAS that handles a REGISTER is given the special name
registrar. Section 10 describes UAC and UAS core behavior for the
REGISTER method. Section 11 describes UAC and UAS core behavior for
the OPTIONS method, used for determining the capabilities of a UA.
这些SIP要素（即用户代理Client和server，无状态和有状态的代理和注册服务）都包含可以彼此区分的核心core。除了无状态代理外，Cores核心都是事务用户UAC和UAS的核心行为虽然依赖于操作，但是所有操作还是有一些通用的规则（第8节）。对于UAC，这些规则确保请求的构建；对于UAS，这些规则确保请求的处理和响应的生成。因为在SIP中“注册”承担了重要角色，所以处理REGISTER的UAS有一个特殊名字registrar。10节描述UAC和UAS针对REGISTER方法的核心行为。11节描述UAC和UAS针对OPTIONS方法（用于判定一个UA的能力）的核心行为。
Certain other requests are sent within a dialog. A dialog is a
peer-to-peer SIP relationship between two user agents that persists
for some time. The dialog facilitates sequencing of messages and
proper routing of requests between the user agents. The INVITE
method is the only way defined in this specification to establish a
dialog. When a UAC sends a request that is within the context of a
dialog, it follows the common UAC rules as discussed in Section 8 but
also the rules for mid-dialog requests. Section 12 discusses dialogs
and presents the procedures for their construction and maintenance,
in addition to construction of requests within a dialog.
在一个dialog中还发送其他特定请求。一个Dialog是两个用户代理间存续一段时间的端对端P2P SIP关系。两个用户代理间，Dialog促进了消息的定序和合理的路由请求。INVITE方法是本标准中建立dialog的唯一方法。在dialog上下文中，当UAC发送请求，UAC不仅遵守第8节中论述的通用的UAC规则，同事还要遵守mid-dialog请求的规则。12节讨论dialog，除了论述构建一个dialog中的请求，还提供其创建和维护的步骤。
The most important method in SIP is the INVITE method, which is used
to establish a session between participants. A session is a
collection of participants, and streams of media between them, for
the purposes of communication. Section 13 discusses how sessions are
initiated, resulting in one or more SIP dialogs. Section 14
discusses how characteristics of that session are modified through
the use of an INVITE request within a dialog. Finally, section 15
discusses how a session is terminated.
SIP中最重要的方法的是被用于建立参加者间会话的INVITE方法。一个会话是为了交流的一组参加者，和他们之间的媒体流。13节讨论会话如何发起，生成一个或多个SIP dialogs。14节讨论一个dialog中，会话的特征/参数如何使用INVITE进行修改。最后，15节讨论如何断开会话。
The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
entirely with the UA core (Section 9 describes cancellation, which
applies to both UA core and proxy core). Section 16 discusses the
proxy element, which facilitates routing of messages between user
agents.
8, 10, 11, 12, 13, 14, 15节的步骤完全围绕UA core(9节描述使用用UA core和proxy core的撤销操作)。16节讨论proxy要素，其完成UA间的消息路由。
6 Definitions 定义
The following terms have special significance for SIP.
SIP中如下术语有特殊含义：
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.
Typically, the location service is populated through
registrations. An AOR is frequently thought of as the "public
address" of the user.
Address-of-Record地址记录:address-of-record (AOR)是一个SIP或SIPS URI，其指向一个域名和位置服务。位置服务可以将一个URI映射为另一个用户可达URI。通常，位置服务通过注册实现。AOR经常被认为是用户的“公开地址”。
Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
logical entity that receives a request and processes it as a
user agent server (UAS). In order to determine how the request
should be answered, it acts as a user agent client (UAC) and
generates requests. Unlike a proxy server, it maintains dialog
state and must participate in all requests sent on the dialogs
it has established. Since it is a concatenation of a UAC and
UAS, no explicit definitions are needed for its behavior.
Back-to-Back User Agent：背对背用户代理(B2BUA) 是作为用户代理服务（UAS），接收和处理请求的一个逻辑实体。为了决定如何回应请求，它又作为用户代理客户（UAC）并生成球球。不像代理服务，它维持dialog状态，必须处理他已经建立的dialog上传输的所有请求。因为它是一个UAC和UAS的级联，不需要对其行为明确定义。
Call: A call is an informal term that refers to some communication
between peers, generally set up for the purposes of a
multimedia conversation.
Call通话:通话是一个非正式术语，指对等体peers之间的通信，通常为了多媒体会话而建立。
Call Leg: Another name for a dialog [31]; no longer used in this
specification.
Call Leg呼叫线路： dialog的另一个名字。本标准中不再使用。
Call Stateful: A proxy is call stateful if it retains state for a
dialog from the initiating INVITE to the terminating BYE
request. A call stateful proxy is always transaction stateful,
but the converse is not necessarily true.
Call Stateful有通话状态的:如果一个代理维护一个dialog从发起INVITE到断开BYE的所有请求，那么这个代理有通话状态的。一个有通话状态的代理通常也有事务状态的，当然反之不一定如此。
Client: A client is any network element that sends SIP requests
and receives SIP responses. Clients may or may not interact
directly with a human user. User agent clients and proxies are
clients.
Client客户：一个客户是一个网络要素，发送SIP请求接收SIP响应。客户可以直接或不直接用一个人类用户交互。
Conference: A multimedia session (see below) that contains
multiple participants.
Conference会议：指一个包含多个参与者的多媒体会话（如下）。
Core: Core designates the functions specific to a particular type
of SIP entity, i.e., specific to either a stateful or stateless
proxy, a user agent or registrar. All cores, except those for
the stateless proxy, are transaction users.
Core核心:核心指 针对 特定类型的SIP实体的功能。比如有状态或者无状态代理，用户代理或注册服务。所有核心不是无状态的代理就是事务用户。
Dialog: A dialog is a peer-to-peer SIP relationship between two
UAs that persists for some time. A dialog is established by
SIP messages, such as a 2xx response to an INVITE request. A
dialog is identified by a call identifier, local tag, and a
remote tag. A dialog was formerly known as a call leg in RFC
2543.
Dialog：Dialog是持续的一段时间内内，两个UA之间一个端对端的SIP关系。Dialog通过SIP消息建立，比如一个针对INVTIE请求的2XX响应。Dialog通过 通话Identifier，本地tag和远端tag 标识。一个dialog之前在RFC2543中被称为通话分支。
Downstream: A direction of message forwarding within a transaction
that refers to the direction that requests flow from the user
agent client to user agent server.
Downstream下行流: 一个事务中消息发送的方向， 指从用户代理客户端发送的请求流向用户代理服务器的方向。
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.
Final Response:最终响应。结束一个SIP事务的响应，不是无法做到结束SIP事务的临时响应。所有的2xx, 3xx, 4xx, 5xx and 6xx 响应都是最终的.
Header: A header is a component of a SIP message that conveys
information about the message. It is structured as a sequence
of header fields.
Header：header是SIP消息的组件，传递消息的信息。它有一系列的头域组成。
Header Field: A header field is a component of the SIP message
header. A header field can appear as one or more header field
rows. Header field rows consist of a header field name and zero
or more header field values. Multiple header field values on a
given header field row are separated by commas. Some header
fields can only have a single header field value, and as a
result, always appear as a single header field row.
头域:偶遇是SIP消息头的组件。一个头域可以有一个或者多个头域行。头域行包括头域名称和零个或者多个头域值。一个给定头域行上的多个头域值通过逗号分开。一些头域只能有一个单独的头域值，所以经常看到的只有一个头域行。
Header Field Value: A header field value is a single value; a
header field consists of zero or more header field values.
Header Field Value：头域值是一个值。一个头域包含零个或多个头域值。
Home Domain: The domain providing service to a SIP user.
Typically, this is the domain present in the URI in the
address-of-record of a registration.
Home Domain:此域给SIP用户提供用户。通常，是出现在注册服务的address-of-record地址记录URI中的域。
Informational Response: Same as a provisional response.
Informational Response：报告响应。参见临时响应。
Initiator, Calling Party, Caller: The party initiating a session
(and dialog) with an INVITE request. A caller retains this
role from the time it sends the initial INVITE that established
a dialog until the termination of that dialog.
发起方，呼叫方，呼叫方：通过INVITE请求发起会话（和dialog）的一方。一个呼叫方从发起INVITE建立dialog至断开dialog期间都保持这个角色。
Invitation: An INVITE request.
Invitation：邀请，一个INVITE请求。
Invitee, Invited User, Called Party, Callee: The party thatreceives an INVITE request for the purpose of establishing a
new session. A callee retains this role from the time it
receives the INVITE until the termination of the dialog
established by that INVITE.
受邀者，受邀用户，被呼叫方，被叫：这一方，收到希望建立一个新会话的INVITE消息。 被叫从收到INVITE至被那个INVITE建立的dialog断开为止。
Location Service: A location service is used by a SIP redirect or
proxy server to obtain information about a callee's possible
location(s). It contains a list of bindings of address-of-
record keys to zero or more contact addresses. The bindings
can be created and removed in many ways; this specification
defines a REGISTER method that updates the bindings.
位置服务：SIP重定向或代理服务使用位置服务获取被叫可能的位置信息。它包含一组AOR keys到零个或者多个联系人地址的绑定。可以通过多种方式建立和删除绑定。本标准定义REGISTER方法更新绑定。
Loop: A request that arrives at a proxy, is forwarded, and later
arrives back at the same proxy. When it arrives the second
time, its Request-URI is identical to the first time, and other
header fields that affect proxy operation are unchanged, so
that the proxy would make the same processing decision on the
request it made the first time. Looped requests are errors,
and the procedures for detecting them and handling them are
described by the protocol.
回环：到达代理的请求，被转发，然后又被同一个代理收到。当它第二次到达，请求URI和第一次相同，其他影响代理操作的头域也没有改变，所以代理回想第一次收到这个消息时一样做相同的决策。回环的消息是错误的。协议中会论述探测和处理回环消息的流程。
Loose Routing: A proxy is said to be loose routing if it follows
the procedures defined in this specification for processing of
the Route header field. These procedures separate the
destination of the request (present in the Request-URI) from
the set of proxies that need to be visited along the way
(present in the Route header field). A proxy compliant to
these mechanisms is also known as a loose router.
松散路由：本规范中定义了处理Route头域的程序。遵循此程序的代理为松散路由代理。这些程序将请求的目的地（出现在Request-URI中）从路径中将要访问的代理集合（出现在Route头域中）剥离。遵循此机制的代理被称为松散路由。
Message: Data sent between SIP elements as part of the protocol.
SIP messages are either requests or responses.
消息:消息是协议中SIP要素之间传输的数据。SIp消息是请求或响应。
Method: The method is the primary function that a request is meant
to invoke on a server. The method is carried in the request
message itself. Example methods are INVITE and BYE.
方法：方法是一个请求将在服务端触发的主要函数。请求消息本身就携带了方法。比如INVITE和BYE就是方法。
Outbound Proxy: A proxy that receives requests from a client, even
though it may not be the server resolved by the Request-URI.
Typically, a UA is manually configured with an outbound proxy,
or can learn about one through auto-configuration protocols.
Outbound Proxy出站代理：这类代理从一个客户接受请求 ，但是它可能不是Request-URI中指明的服务器。通常一个UA可以配置一个出站代理，或者通过自动化配置协议清除出站代理。
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.
并发查找：在并发查找并，一个代理接收到incoming请求可能会向一个可能的用户地址转发请求。相比顺序查找（在发下一个下次前，先发一个消息，然后等待最终响应），并发查找不用等待上一个请求的响应既可以发出多个请求。
Provisional Response: A response used by the server to indicate
progress, but that does not terminate a SIP transaction. 1xx
responses are provisional, other responses are considered
final.
临时响应：服务端用于表明正在处理的响应，但是这种响应不会结束SIP事务。1XX响应是临时响应，其他响应都是最终响应。
Proxy, Proxy Server: An intermediary entity that acts as both a
server and a client for the purpose of making requests on
behalf of other clients. A proxy server primarily plays the
role of routing, which means its job is to ensure that a
request is sent to another entity "closer" to the targeted
user. Proxies are also useful for enforcing policy (for
example, making sure a user is allowed to make a call). A
proxy interprets, and, if necessary, rewrites specific parts of
a request message before forwarding it.
代理，代理服务：即充当客户端也充当服务端的媒介实体，其存在是为了代表其他客户发送请求。一个代理服务主要扮演路由的角色。这意味他的主叫工作是为了将请求发到另一个离目标用户“更近”的实体。代理在执行策略时也很有用（比如，确保一个用户是有权限打电话的）。代理在转发请求前，会解释并且如果必要会重写请求消息的特定部分。
Recursion: A client recurses on a 3xx response when it generates a
new request to one or more of the URIs in the Contact header
field in the response.
递归：3XX响应导致客户“递归”，即客户会发出新的请求到 响应中contact头域的一个或多个URI。
Redirect Server: A redirect server is a user agent server that
generates 3xx responses to requests it receives, directing the
client to contact an alternate set of URIs.
重定向服务器：一个重定向服务是收到请求后发出3XX响应的用户代理服务，将用户重定向，去联系另外一组URI。
Registrar: A registrar is a server that accepts REGISTER requests
and places the information it receives in those requests into
the location service for the domain it handles.
Registrar注册服务：一个Registrar是一个接收REGISTER请求的服务。它将这些请求中的信息放到它在域中控制的位置服务。
Regular Transaction: A regular transaction is any transaction with
a method other than INVITE, ACK, or CANCEL.
常规事务：常规事务是除了INVITE、ACK或CANCEL方法之外的任何事务。
Request: A SIP message sent from a client to a server, for the
purpose of invoking a particular operation.
请求：从客户端发送到服务器的SIP消息，用于调用特定的操作。
Response: A SIP message sent from a server to a client, for
indicating the status of a request sent from the client to the
server.
响应：从服务器发送到客户端的SIP消息，用于指示从客户端发送到服务器的请求的状态。
Ringback: Ringback is the signaling tone produced by the callingparty's application indicating that a called party is being
alerted (ringing).
回铃：回铃是由主叫方的应用程序产生的信号音，表示被叫方正在被提醒（振铃）。
Route Set: A route set is a collection of ordered SIP or SIPS URI
which represent a list of proxies that must be traversed when
sending a particular request. A route set can be learned,
through headers like Record-Route, or it can be configured.
路由集合：路由集合是有序SIP或SIPS URI的集合，它代表在发送特定请求时必须遍历的代理列表。可以通过Record-Route之类的头域来生成路由集，或者也可以配置路由集。
服务器：服务器是一个网络单元，它接收请求、服务它们并向这些请求发送回响应。服务器的例子有：代理服务器、用户代理服务器、重定向服务器和注册服务器。
Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search.
顺序搜索：在顺序搜索中，代理服务器尝试顺序联系每一个地址，只有上一个生成了最终响应，才会处理下一个。通常 2XX和6XX类的最终响应终结一个顺序搜索。
Session: From the SDP specification: "A multimedia session is a
set of multimedia senders and receivers and the data streams
flowing from senders to receivers. A multimedia conference is
an example of a multimedia session." (RFC 2327 [1]) (A session
as defined for SDP can comprise one or more RTP sessions.) As
defined, a callee can be invited several times, by different
calls, to the same session. If SDP is used, a session is
defined by the concatenation of the SDP user name, session id,
network type, address type, and address elements in the origin
field.
会话：按照SDP标准：“一个多媒体会话是一组多媒体发送和接收方，以及发送和接收方之间流动的数据流。一个多媒体会议是多媒体会话的例子。” (RFC 2327 [1])（SDP中定义的会话可以包括一个或多个RTP会话）。参照定义，在同一个会话中，被叫方可以被不同的主叫邀请多次。如果使用SDP，会话则由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. If the request is INVITE
and the final response is a non-2xx, the transaction also
includes an ACK to the response. The ACK for a 2xx response to
an INVITE request is a separate transaction.
SIP事务：一个SIP事务发送在客户和服务器之间，包含从从客户向服务器发出的第一个请求到服务器发给客户的最终响应（非1xx）。如果请求是INVITE，最终响应是非2XX，这个事务也包含这个最终响应的ACK。如果一个INVITE的请求的响应是2XX响应，那么2XX响应的ACk是一个独立的事务。
Spiral: A spiral is a SIP request that is routed to a proxy,
forwarded onwards, and arrives once again at that proxy, but
this time differs in a way that will result in a different
processing decision than the original request. Typically, this
means that the request's Request-URI differs from its previous
arrival. A spiral is not an error condition, unlike a loop. A
typical cause for this is call forwarding. A user calls
[email protected]. The example.com proxy forwards it to Joe's
PC, which in turn, forwards it to [email protected]. This
request is proxied back to the example.com proxy. However,
this is not a loop. Since the request is targeted at a
different user, it is considered a spiral, and is a valid
condition.
螺旋：螺旋指路由到某个代理的SIP请求被转发出去后，又再一次到达这个代理，但是这次和原始请求相比，处理方式不同，导致了不同的处理决策。通常，这意味着请求的Request-URI不同于上一次到达时的Request-URI。不同于回环，螺旋不是错误情况。通常是呼叫转移导致螺旋。一个用户呼叫[email protected]。example.com代理将其转移至Joe的PC，即将其转移至 [email protected].这个请求返回到 example.com代理。但这种情况不是回环。因为请求指向了不同用户，这种情况被认为是螺旋，一种合法情况。
Stateful Proxy: A logical entity that maintains the client and
server transaction state machines defined by this specification
during the processing of a request, also known as a transaction
stateful proxy. The behavior of a stateful proxy is further
defined in Section 16. A (transaction) stateful proxy is not
the same as a call stateful proxy.
有状态代理：此逻辑实体 按照标准规范，维护客户和服务事务状态机，以处理请求。也被称为事务状态代理。 一个有状态代理的行为在16节论述。（事务）状态代理和呼叫状态代理是等价的。
Stateless Proxy: A logical entity that does not maintain the
client or server transaction state machines defined in this
specification when it processes requests. A stateless proxy
forwards every request it receives downstream and every
response it receives upstream.
无状态代理：处理请求时，不按照本协议规范维护一个请求或服务事务状态机的逻辑实体。一个无状态代理转发在下行流收到的每一个请求和在上行流收到的每一个响应。
Strict Routing: A proxy is said to be strict routing if it follows
the Route processing rules of RFC 2543 and many prior work in
progress versions of this RFC. That rule caused proxies to
destroy the contents of the Request-URI when a Route header
field was present. Strict routing behavior is not used in this
specification, in favor of a loose routing behavior. Proxies
that perform strict routing are also known as strict routers.
严格路由：这类路由 遵循RFC2543标准中路由规则，也 遵循这个版本标准的其他许多先行工作规范。当存在Route头域时，这些规则使代理破坏Request-URI 的内容。在本规范中不用严格路由行为，而使用松散路由行为。 执行严格路由的代理也被称为严格路由器。
Target Refresh Request: A target refresh request sent within a
dialog is defined as a request that can modify the remote
target of the dialog.
目标刷新请求：dialog中发送此请求可以修改dialog的远端目的地。
Transaction User (TU): The layer of protocol processing that
resides above the transaction layer. Transaction users include
the UAC core, UAS core, and proxy core.
事务用户（TU）：协议的这一层运行在事务层之上。TU包括 UAC core，UAS core，和Proxy CORE。
Upstream: A direction of message forwarding within a transaction
that refers to the direction that responses flow from the user
agent server back to the user agent client.
上行流：一个事务中，从用户代理服务器到用户代理客户的响应流的方向。
URL-encoded: A character string encoded according to RFC 2396,
Section 2.4 [5].
URL编码：RFC2396 2.4节中的编码字符串。
User Agent Client (UAC): A user agent client is a logical entity
that creates a new request, and then uses the client
transaction state machinery to send it. The role of UAC lasts
only for the duration of that transaction. In other words, if
a piece of software initiates a request, it acts as a UAC for
the duration of that transaction. If it receives a request
later, it assumes the role of a user agent server for the
processing of that transaction.
用户代理（UAC）：用户代理客户段是一个产生请求，并使用客户段事务状态机发送请求的逻辑实体。UAC角色仅仅存在于事务的生命期内。或者说，如果软件的一部分发起一个请求，那么在这个事务的生存期内，软件的这部分的行为被称为UAC。如果后续它收到请求，在那个个事务处理中，其角色又成为用户代理服务端。
UAC Core: The set of processing functions required of a UAC that
reside above the transaction and transport layers.
UAC 核心：UAC在传输层和事务之上的处理函数集。
User Agent Server (UAS): A user agent server is a logical entity
that generates a response to a SIP request. The response
accepts, rejects, or redirects the request. This role lasts
only for the duration of that transaction. In other words, if
a piece of software responds to a request, it acts as a UAS for
the duration of that transaction. If it generates a request
later, it assumes the role of a user agent client for the
processing of that transaction.
用户代理服务端（UAS）：收到SIP 请求生成响应的逻辑实体。此响应可以接受，拒绝或转发这个请求。其角色仅存在事务的生存期内。换句换说，如果软件的一部分响应一个请求，在那个事务的生存期内，其行为就是UAS。如果后面，它生成了一个请求，那么在那个事务运行过程中，其行为是用户代理客户端。
UAS Core: The set of processing functions required at a UAS that
resides above the transaction and transport layers.
UAS 核心：UAS在传输层和事务层之上的处理函数集。
User Agent (UA): A logical entity that can act as both a user
agent client and user agent server.
用户代理（UA）：既可以充当用户代理客户端，有可以充当用户代理服务器的逻辑实体。
The role of UAC and UAS, as well as proxy and redirect servers, are
defined on a transaction-by-transaction basis. For example, the user
agent initiating a call acts as a UAC when sending the initial INVITE
request and as a UAS when receiving a BYE request from the callee.
Similarly, the same software can act as a proxy server for one
request and as a redirect server for the next request.
UAC、UAS角色，以及代理和重定向服务器，都围绕事务定义。比如，当用户代理发起一个INVITE请求来触发通话，其充当UAC；当其从被叫方收到BYE请求时，其充当UAS。类似的，同一个软件 对一个请求而言可以充当代理服务器，但对下一个请求又可以充当重定向服务器。
Proxy, location, and registrar servers defined above are logical
entities; implementations MAY combine them into a single application.
代理，位置，注册服务器定义在逻辑实体之上；实现时可以将这些结合到一个单独应用中。
7 SIP Messages SIP消息
SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279[7]).
SIP是一个基于文本的协议。使用 UTF-8 编码(RFC 2279 [7]).。
A SIP message is either a request from a client to a server, or a
response from a server to a client.
一个SIP消息要么是从客户端到服务端请求，要么是一个从服务端到客户端响应。
Both Request (section 7.1) and Response (section 7.2) messages use
the basic format of RFC 2822 [3], even though the syntax differs in
character set and syntax specifics. (SIP allows header fields that
would not be valid RFC 2822 header fields, for example.) Both types
of messages consist of a start-line, one or more header fields, an
empty line indicating the end of the header fields, and an optional
message-body.
所有消息（7.1节）和响应（7.2节）使用RFC2822[3]中定义的基本格式。虽然语法细节和字符集的语法不同。（比如，SIP允许的一些头域在RFC2822中不合法。）所有类型消息，包含开始行，一个或多个空行，只是头域借宿的空行，可一个可选的消息体。
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
The start-line, each message-header line, and the empty line MUST be
terminated by a carriage-return line-feed sequence (CRLF). Note that
the empty line MUST be present even if the message-body is not.
开始行、每一个消息头行、空白行，必须以carriage-return回车 line-feed换行 (CRLF)结束。注意：计时一个消息没有消息体，也必须出现空白行。
Except for the above difference in character sets, much of SIP's
message and header field syntax is identical to HTTP/1.1. Rather
than repeating the syntax and semantics here, we use [HX.Y] to refer
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).
除了上述 字符集的不同，很多SIP消息和头部语法和HTTP/1.1是相同的。与其在这里重复这些语法和雨衣，我们使用[HX.Y]来引用现在的 HTTP/1.1 标准 (RFC 2616 [8])的X.Y 节。
However, SIP is not an extension of HTTP.
但是,SIP并不是HTTP的扩展。
7.1 Requests 请求
SIP requests are distinguished by having a Request-Line for a start-
line. A Request-Line contains a method name, a Request-URI, and the
protocol version separated by a single space (SP) character.
SIP请求的起始行被称为请求行。一个请求行包含一个方法名，一个Request-URI，和一个协议号，三者之间通过一个 单空白符（SP）分割。
The Request-Line ends with CRLF. No CR or LF are allowed except in
the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed
in any of the elements.
请求行以CRLF结束。除了一行结束的CRLF序列，其他的CR或LF都不允许。任何一个元素中也不能出现线性空白符。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method: This specification defines six methods: REGISTER for
registering contact information, INVITE, ACK, and CANCEL for
setting up sessions, BYE for terminating sessions, and
OPTIONS for querying servers about their capabilities. SIP
extensions, documented in standards track RFCs, may define
additional methods.
方法：本协议定义六个方法：REGISTER 注册联系信息，INVITE，ACK，CANCEL 正在建立的会话，BYE 断开会话，OPTIONS 查询服务器的能力。其他做为SIP扩展的RFC标准可以定义额外的方法。
Request-URI: The Request-URI is a SIP or SIPS URI as described in
Section 19.1 or a general URI (RFC 2396 [5]). It indicates
the user or service to which this request is being addressed.
The Request-URI MUST NOT contain unescaped spaces or control
characters and MUST NOT be enclosed in "<>".
Request-URI:是在19.1节中定义的SIP或SIPS URI，或者是一个通用URI (RFC 2396 [5])。它指出 被寻址的请求 指向的用户或服务。 Request-URI必须不包含 unescaped spaces或者控制符，也不能放入"<>"中。
SIP elements MAY support Request-URIs with schemes other than
"sip" and "sips", for example the "tel" URI scheme of RFC
2806 [9]. SIP elements MAY translate non-SIP URIs using any
mechanism at their disposal, resulting in SIP URI, SIPS URI,
or some other scheme.
SIP元素可能不支持Request-URIs中出现“SIP”和“SIPS”值外的schemes，比如RFC2806 [9]中的"tel" URI scheme.SIP元素可以使用任何机制转换一个非SIP URI，转换为SIP URI，SIPS URI，或者其他scheme。
SIP-Version: Both request and response messages include the
version of SIP in use, and follow [H3.1] (with HTTP replaced
by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version
ordering, compliance requirements, and upgrading of version
numbers. To be compliant with this specification,
applications sending SIP messages MUST include a SIP-Version
of "SIP/2.0". The SIP-Version string is case-insensitive,
but implementations MUST send upper-case.
SIP版本：请求和响应都包含使用的SIP版本。根据遵循的版本，兼容的需求和版本号的升级，按照[3.1](HTTP替换为SIP，HTTP/1.1 替换为SIP/2.0)。若兼容本协议，应用发送SIP消息必须包含“SIP/2.0”的SIP版本号。SIP版本号字符串是大小写不敏感的，但是实现必须发送大写。
Unlike HTTP/1.1, SIP treats the version number as a literal
string. In practice, this should make no difference.
和HTTP/1.1不同，SIP将版本号当字符串处理。 在实践中，这个没有什么区别。
7.2 Responses 响应
SIP responses are distinguished from requests by having a Status-Line
as their start-line. A Status-Line consists of the protocol version
followed by a numeric Status-Code and its associated textual phrase,
with each element separated by a single SP character.
不同于请求，SIP的首行被称为状态行。一个状态行包含协议号，然后跟着 数字状态码，和相关的文本短语phrase。每一个元素被一个单独SP字符分开。
No CR or LF is allowed except in the final CRLF sequence.
除了最后的CRLF序列，不允许出现CR或LF。
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
The Status-Code is a 3-digit integer result code that indicates the
outcome of an attempt to understand and satisfy a request. The
Reason-Phrase is intended to give a short textual description of the
Status-Code. The Status-Code is intended for use by automata,
whereas the Reason-Phrase is intended for the human user. A client
is not required to examine or display the Reason-Phrase.
状态码是一个3位数字结果码，是一个 尝试理解和满足请求的输出。 原因短语Reason-Phrase给一个状态码的简单字面解释。状态码用于程序处理，原因短语Reason-Phrase用于显示给人类用户。不要求客户端检查或显示原因短语。
While this specification suggests specific wording for the reason
phrase, implementations MAY choose other text, for example, in the
language indicated in the Accept-Language header field of the
request.
虽然协议建议了原因短语的标准措辞，实现可以选择其他文本。比如使用请求的头域中指出的 Accept-Language 。
The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. For this
reason, any response with a status code between 100 and 199 is
referred to as a "1xx response", any response with a status code
between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows
six values for the first digit:
状态码的第一个数字定义了响应的分类。后两个数字和响应的分类无关。所以，任何一个100到199之间的状态码都称为“1XX响应”，任何一个200到299之间的状态码都称为“2XX响应”，以此类推。SIP/2.0 准许第一个数字有六个值。
1xx: Provisional -- request received, continuing to process the
request;
1xx: 临时 --请求收到，正在处理请求。
2xx: Success -- the action was successfully received, understood,
and accepted;
2XX：成功--操作 成功收到，理解和接受。
3xx: Redirection -- further action needs to be taken in order to
complete the request;
3xx: 重定向--为了完成此请求需要进一步的操作。
4xx: Client Error -- the request contains bad syntax or cannot be
fulfilled at this server;
4xx: 客户端失败--请求包含错误语法或者不能被服务端执行。
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: 全局失败 -- 这个请求任何服务器都无法执行。
Section 21 defines these classes and describes the individual codes.
21节定义这些分类，并讨论不同的码。
7.3 Header Fields头域
SIP header fields are similar to HTTP header fields in both syntaxand semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax for the message-header and the rules for
extending header fields over multiple lines. However, the latter is
specified in HTTP with implicit whitespace and folding. This
specification conforms to RFC 2234 [10] and uses only explicit
whitespace and folding as an integral part of the grammar.
在语法和语义上，SIP头域都类似于HTTP头域。特别是，SIP头域遵循[H4.2]的消息头语法定义和跨多行的扩展头域准则。然而，后者HTTP中指定了隐式空白和折叠。此规范符合RFC 2234 [10] ，只使用显式空白和折叠作为语法的一个组成部分。
[H4.2] also specifies that multiple header fields of the same field
name whose value is a comma-separated list can be combined into one
header field. That applies to SIP as well, but the specific rule is
different because of the different grammars. Specifically, any SIP
header whose grammar is of the form
[H4.2] 也定义了有相同头域名（这个头域名的值是一个逗号分隔的list）的多行头域可以组成一个头域。这个对SIP也适用。但是这个特殊规则在不同的语法下是不同的。明确的，任何其语法符合下列各式的SIP头域：
header = "header-name" HCOLON header-value *(COMMA header-value)
allows for combining header fields of the same name into a comma-
separated list. The Contact header field allows a comma-separated
list unless the header field value is "*".
才允许将有相同名字的头域合成一个逗号分隔的列表。 如果头域值不是"*"，Contact头域允许逗号分隔的列表。（这句话翻译的有问题？）
7.3.1 Header Field Format头域格式
Header fields follow the same generic header format as that given in
Section 2.2 of RFC 2822 [3]. Each header field consists of a field
name followed by a colon (":") and the field value.
头域和 RFC 2822 [3]的2.2节给的通用头规范相同。每一个头域包含一个头域值，跟着一个分好(":")和一个头域值。
field-name: field-value
The formal grammar for a message-header specified in Section 25
allows for an arbitrary amount of whitespace on either side of the
colon; however, implementations should avoid spaces between the field
name and the colon and use a single space (SP) between the colon and
the field-value.
正式的消息头语法在25节定义。允许分号两侧有任意数量的空白符。但是实现的时候应该避免在头域名和分号有空白，并在分号和头域值之间使用 single space (SP)。
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
Thus, the above are all valid and equivalent, but the last is the
preferred form.
所以，上面的几个例子都是合法和等价的，但是只有最后一个才是推荐格式。
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or horizontal tab (HT). The line
break and the whitespace at the beginning of the next line are
treated as a single SP character. Thus, the following are
equivalent:
头域可以通过每个附加行以至少一个SP或平行tab (HT)开头，来扩展为多行。被拆开的行和下一行开头的空白被认为是一个单独SP字符。所以下面两个是等价的。
Subject: I know you're there, pick up the phone and talk to me!
Subject: I know you're there,
pick up the phone
and talk to me!
The relative order of header fields with different field names is not
significant. However, it is RECOMMENDED that header fields which are
needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
Max-Forwards, and Proxy-Authorization, for example) appear towards
the top of the message to facilitate rapid parsing. The relative
order of header field rows with the same field name is important.
Multiple header field rows with the same field-name MAY be present in
a message if and only if the entire field-value for that header field
is defined as a comma-separated list (that is, if follows the grammar
defined in Section 7.3). It MUST be possible to combine the multiple
header field rows into one "field-name: field-value" pair, without
changing the semantics of the message, by appending each subsequent
field-value to the first, each separated by a comma. The exceptions
to this rule are the WWW-Authenticate, Authorization, Proxy-
Authenticate, and Proxy-Authorization header fields. Multiple header
field rows with these names MAY be present in a message, but since
their grammar does not follow the general form listed in Section 7.3,
they MUST NOT be combined into a single header field row.
不同头域名的的头域顺序是无意义的。但是为了处理速度，建议需要代理处理的头域（比如Via, Route, Record-Route, Proxy-Require, Max-Forwards和 Proxy-Authorization）放在消息的顶部。相同头域的头域行的相对顺序是有意义的。只有一个头域的整个头域值定义为逗号分隔行（即，符合7.3节定义的语法），这个头域才能以多行头域行出现在消息里。将多行头域转换为一行“头域名: 头域值”，必须不能改变消息的语义，将每一个后续头域值放在第一个后面，以逗号分隔。这个规则的特例是WWW-Authenticate, Authorization, Proxy-Authenticate和 Proxy-Authorization头域。因为他们的语法不服务7.3定义的通用格式，所以即使当它们出现多个头域行，它们也必须不能组合个为单个头域行。
Implementations MUST be able to process multiple header field rows
with the same name in any combination of the single-value-per-line or
comma-separated value forms.
实现必须有能力处理同个名称的多行头域。多行头域可以是 “一行单值” 或者是 “逗号分隔值” 格式的任何组合。
The following groups of header field rows are valid and equivalent:
如下的头域行组是合法和等价的。
Route:
Subject: Lunch
Route:
Route:
Route:
Route:
Subject: Lunch
Subject: Lunch
Route:
Each of the following blocks is valid but not equivalent to the
others:
如下的快是有效的，但是彼此不等价。
Route:
Route:
Route:
Route:
Route:
Route:
Route:
The format of a header field-value is defined per header-name. It
will always be either an opaque sequence of TEXT-UTF8 octets, or a
combination of whitespace, tokens, separators, and quoted strings.
Many existing header fields will adhere to the general form of a
value followed by a semi-colon separated sequence of parameter-name,
parameter-value pairs:
每一个头域名的头域值都单独定义。头域值要么是不透明的UTF8文本八位字节序列，要么是空白符，标记，分隔符，带引号的字符串组合。现有很多头域遵循如下通用格式--头域值，其后用冒号分隔，跟着一个参数名，参数值对构成的序列。
field-name: field-value *(;parameter-name=parameter-value)
Even though an arbitrary number of parameter pairs may be attached to
a header field value, any given parameter-name MUST NOT appear more
than once.
即使允许头域值后有任意数量的参数对。但是任何一个参数名不能出现多于1次。
When comparing header fields, field names are always case-
insensitive. Unless otherwise stated in the definition of a
particular header field, field values, parameter names, and parameter
values are case-insensitive. Tokens are always case-insensitive.
Unless specified otherwise, values expressed as quoted strings are
case-sensitive. For example,
当比较头域，头域名时，都是大小写不敏感的。如果某个头域的定义没有特别指明，头域、头域值、参数名和参数值是大小写不敏感的。标签总是不敏感的。如果没有特别说明，引号括起的值是大小写敏感的。
Contact:
is equivalent to
CONTACT:
上面两个等价。
and
Content-Disposition: session;handling=optional
is equivalent to
content-disposition: Session;HANDLING=OPTIONAL
上面两个等价。
The following two header fields are not equivalent:
Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"
上面两个不等价。
7.3.2 Header Field Classification头域分类
Some header fields only make sense in requests or responses. Theseare called request header fields and response header fields,
respectively. If a header field appears in a message not matching
its category (such as a request header field in a response), it MUST
be ignored. Section 20 defines the classification of each header
field.
一些头域只有在请求或响应中才有意义。这些头域分别被分类为 请求头域 或者 响应头域。如果消息中一个头域不符合其分类（比如请求头域出现在响应消息里），这个头域必须忽略。20节定义了每个头域的分类。
7.3.3 Compact Form 紧凑形式
SIP provides a mechanism to represent common header field names in anabbreviated form. This may be useful when messages would otherwise
become too large to be carried on the transport available to it
(exceeding the maximum transmission unit (MTU) when using UDP, for
example). These compact forms are defined in Section 20. A compact
form MAY be substituted for the longer form of a header field name at
any time without changing the semantics of the message. A header
field name MAY appear in both long and short forms within the same
message. Implementations MUST accept both the long and short forms
of each header name.
SIP提供以缩写形式表示公共头域名的机制。如果不缩写就超过传输能力的情况下（比如，使用UDP时超过了最大传输单元（MTU）），这个机制就比较有效。在任何情况下，都可以将头域名的长格式替换为紧凑格式，并且消息的语义不变。在同一个消息内一个头域名的长格式和短格式可以同时出现。实现方案必须支持每一个头域名的长格式和短格式。
7.4 Bodies 消息体
Requests, including new requests defined in extensions to thisspecification, MAY contain message bodies unless otherwise noted.
The interpretation of the body depends on the request method.
如果没有特别说明，此协议和其扩展协议中定义的请求可能包含消息体。消息体的解释依赖于请求方法。
For response messages, the request method and the response status
code determine the type and interpretation of any message body. All
responses MAY include a body.
针对响应消息，请求消息和响应状态码决定了消息体的类型和解释。所有的响应都可以包含消息体。
7.4.1 Message Body Type消息体类型
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头域中给出。如果消息体经过了任何编码，比如压缩，那么Content-Encoding头域必须给出相关信息。否则省略Content-Encoding。如果适用，Content-Type头域值指出消息体的字符集。
The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
the body of the message. Implementations that send requests
containing multipart message bodies MUST send a session description
as a non-multipart message body if the remote implementation requests
this through an Accept header field that does not contain multipart.
在RFC 2046 [11]中定义的"multipart" MIME 类型可以用在消息体。如果一个远端实现请求 有 不包含multipart的 Accept头域，那么本端 发送的请求虽然包含 multipart消息体，发送会话描述是只能用non-multipart的消息体。
SIP messages MAY contain binary bodies or body parts. When no
explicit charset parameter is provided by the sender, media subtypes
of the "text" type are defined to have a default charset value of
"UTF-8".
SIP消息可以包含二进制消息体或消息体部分。 当发送方没有特别之处字符集参数，媒体子类型被认为是 默认的UTF-8字符集的 "文本"类型。
7.4.2 Message Body Length 消息体长度
The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the necessary contents of this header field in detail. Content-Length 头域提供了消息体的字节长度。20.14节将详细描述此头域的必要contents。 The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.)
SIP必须不使用HTTP/1.1中的分包传输编码。（注:为了将其作为一组包传输，分段编码修改消息体，每一个包都有自己的大小指示。）
7.5 Framing SIP Messages 构造SIP消息
Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such datagram carries one request or response. See Section 18 on constraints on usage of unreliable transports.不像HTTP，SIP消息可以使用UDP或其他不可靠数据报协议。这种报文携带一个请求或响应。参见18节，论述了不可靠传输的使用限制。
Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line[H4.1].
建立在面向流的传输上的处理SIP消息的实现，必须忽略start-line首行前的所有CRLF[H4.1].。
The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports.Content-Length头域值用来定位一个流中SIP消息的结束位置。在面向流的传输中，SIP消息中总是出现这个头域。
8 General User Agent Behavior 一般的用户代理行为
A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A UAS is capable of receiving a request and generating a response based on user input, external stimulus, the result of a program execution, or some other mechanism.用户代理代表端系统。它包含产生请求的用户代理客户端（UAC），和响应请求的用户代理服务端（UAS）。UAC的能力包括在外部刺激（用户点击按钮，或者PSTN线路上的信号）下生成请求，并处理响应。UAS能接收请求，并根据用户输入，外部刺激，程序处理结果，或者其他机制生成响应。
When a UAC sends a request, the request passes through some number of proxy servers, which forward the request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC.
当UAC发送请求，请求通过一些代理服务。这些代理服务将请求转发到UAS。当UAS生成响应，响应被转发到UAC。
UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE.
UAC和UAS的具体行为和两个因素强相关。第一个，和请求或响应是在一个dialog之内还是之外。第二个因素和请求方法相关。Dialog在12节中详细讨论。Dialogs代表了用户代理间的P2P对等关系。Dialog由特定的SIP方法建立，比如INVITE。
In this section, we discuss the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog. This includes, of course, the requests which themselves establish a dialog.
本节中，将要讨论UAC和UAS和方法无关的规则（当消息在dialog外处理）。当然，包含建立dialog的请求。
Security procedures for requests and responses outside of a dialog are described in Section 26. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features are also supported through encryption of bodies using S/MIME.
dialog外的请求和响应的安全操作在26节中讨论。具体说是UAS和UAC的相互认证机制。通过使用S/MIME加密消息体，也支持一些有限的隐私特征集。
8.1 UAC Behavior UAC行为
This section covers UAC behavior outside of a dialog. 本节包含dialog外的UAC行为。8.1.1 Generating the Request 生成请求
A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. These header fields are in addition to the mandatory request line, which contains the method, Request-URI, and SIP version.UAC构造的合法SIP请求必须至少包含如下头域：To, From, CSeq, Call-ID, Max-Forwards和Via; 这些头域在所有SIP请求中都是强制的。这六个头域是SIP消息的基本构造块。它们共同提供了最重要的消息路由服务，包含：消息寻址，响应路由，消息蔓延限制，消息排序，事务唯一标识。这些头域跟在“强制请求行”后面。“强制请求行”包含方法， Request-URI，和SIP版本。
Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11).
dialog外发送的请求示例包括建立会话的INVITE（13节）和查询能力的OPTIONS（11节）。
8.1.1.1 Request-URI
the URI in the To field. One notable exception is the REGISTER
method; behavior for setting the Request-URI of REGISTER is given in
Section 10. It may also be undesirable for privacy reasons or
convenience to set these fields to the same value (especially if the
originating UA expects that the Request-URI will be changed during
transit).
消息 的初始Request-URI应该放到TO域的URI值。不过有一个非常值得注意的特例--REGISTER方法；设置REGISTER中Request-URI的行为在10节中描述。有时出于隐私或方便，Request-URI和TO域设置为相同值也是不可取的（特别是，如果初始UA期望在发送途中更改Request-URI值）。
In some special circumstances, the presence of a pre-existing route
set can affect the Request-URI of the message. A pre-existing route
set is an ordered set of URIs that identify a chain of servers, to
which a UAC will send outgoing requests that are outside of a dialog.
Commonly, they are configured on the UA by a user or service provider
manually, or through some other non-SIP mechanism. When a provider
wishes to configure a UA with an outbound proxy, it is RECOMMENDED
that this be done by providing it with a pre-existing route set with
a single URI, that of the outbound proxy.
在一些特殊环境中，预先存在的路由集会影响消息的Request-URI。预先存在的路由集是定义服务器链的URI有序组合。UAC的dialog之外输出请求会发给它们。通常，用户或服务提供者手动配置UA上的路由集，或者通过一些非SIP机制。当一个提供者希望给UA配置一个outbound 代理，建议用预先存在的路由集和 outbound代理的单个URI实现这一点。（这一句话不懂！！）
When a pre-existing route set is present, the procedures for
populating the Request-URI and Route header field detailed in Section
12.2.1.1 MUST be followed (even though there is no dialog), using the
desired Request-URI as the remote target URI.
当存在预先存在的路由集，构造Request-RI和路由头域的过程在12.2.1.1中详细论述。这个过程要严格遵守（即使没有dialog）。要使用合适的Request-URI作为远程目标URI。
8.1.1.2 To
The To header field first and foremost specifies the desired
"logical" recipient of the request, or the address-of-record of the
user or resource that is the target of this request. This may or may
not be the ultimate recipient of the request. The To header field
MAY contain a SIP or SIPS URI, but it may also make use of other URI
schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.
All SIP implementations MUST support the SIP URI scheme. Any
implementation that supports TLS MUST support the SIPS URI scheme.
The To header field allows for a display name.
TO头部域重点指定了请求的 预期“逻辑”接收者，或者请求目标指定的用户或资源的地址记录（AOC）。其值可以是请求的最终接收者，也可以不是。TO头域可以包含SIP或SIPS URI，如果合适也可以使用其他URI格式（比如 tel URL (RFC 2806 [9])）.任何支持TLS的实现，必须支持SIPS URI格式。TO头域也允许显示名。
A UAC may learn how to populate the To header field for a particular
request in a number of ways. Usually the user will suggest the To
header field through a human interface, perhaps inputting the URI
manually or selecting it from some sort of address book. Frequently,
the user will not enter a complete URI, but rather a string of digits
or letters (for example, "bob"). It is at the discretion of the UA
to choose how to interpret this input. Using the string to form the
user part of a SIP URI implies that the UA wishes the name to be
resolved in the domain to the right-hand side (RHS) of the at-sign in
the SIP URI (for instance, sip:[email protected]). Using the string to
form the user part of a SIPS URI implies that the UA wishes to
communicate securely, and that the name is to be resolved in the
domain to the RHS of the at-sign. The RHS will frequently be the
home domain of the requestor, which allows for the home domain to
process the outgoing request. This is useful for features like
"speed dial" that require interpretation of the user part in the home
domain. The tel URL may be used when the UA does not wish to specify
the domain that should interpret a telephone number that has been
input by the user. Rather, each domain through which the request
passes would be given that opportunity. As an example, a user in an
airport might log in and send requests through an outbound proxy in
the airport. If they enter "411" (this is the phone number for local
directory assistance in the United States), that needs to be
interpreted and processed by the outbound proxy in the airport, not
the user's home domain. In this case, tel:411 would be the right
choice.
针对特定请求，UAC可以通过多种不同方式构造TO头域。通常用户可以通过人机界面建议TO头域值，可能手动输入URI或者从地址本的部分记录中选择一个。往往用户不会输入完整的URI，而只是一个数字或字符串（比如“bob”）。UA自行决定如何解释输入。用输入字符串构造 SIP URI的用户部分，意味着UA希望域名作为SIP URI中@字符的右侧（right-hand side (RHS)）部分（比如sip:[email protected]）。使用输入字符串作为SIPS URI的用户部分，意味着UA希望安全的交流，域名作为SIPS URI的@字符右侧RHS。RHS右侧经常是请求的home 域。针对"快速拨号"特性，这个构造方法很有用，因为"快速拨号"需要home 域解析用户部分。当当用户输入的是电话号码，UA不希望指定域时，可以使用tel URL. 这样请求通过的每一个域都有处理这个请求的机会。 举个例子，一个用户登入一个机场，通过机场的一个outbound代理发出请求。如果输入“411”（美国的本地救援号码），这就需要机场的outbound 代理处理和解释，而不是用户的home 域处理。本例中，tel:411是正确的选择。
A request outside of a dialog MUST NOT contain a To tag; the tag in
the To field of a request identifies the peer of the dialog. Since
no dialog is established, no tag is present.
dialog外的请求一定不能包含TO tag。To域中的tag表示请求在dialog中的对端。因为dialog还没有建立，tag 不能出现。
For further information on the To header field, see Section 20.39.
The following is an example of a valid To header field:
TO头域的进一步论述请见20.39节。下面是一个合法的To头域的例子。
To: Carol
8.1.1.3 From
The From header field indicates the logical identity of the initiatorof the request, possibly the user's address-of-record. Like the To
header field, it contains a URI and optionally a display name. It is
used by SIP elements to determine which processing rules to apply to
a request (for example, automatic call rejection). As such, it is
very important that the From URI not contain IP addresses or the FQDN
of the host on which the UA is running, since these are not logical
names.
From头域显示了请求发起者的逻辑表示，可能是用户的地址记录。类似To头域，它包含一个URI，还有可能有个显示名。SIP元素通过From域来选择处理请求的运行规则（比如，自动拒绝呼叫）。因此，有一点非常重要，就是From URI不能包含UA所在主机的IP地址或者FQDN（全限定域名）（因为它们不包含逻辑名）。
The From header field allows for a display name. A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:[email protected]), if the
identity of the client is to remain hidden.
From由于允许显示名。如果客户端标识将被隐藏，UAC应当用显示名"Anonymous"（匿名）,跟着一个语法正确但是没有实际意义的URI（比如 sip:[email protected]）。
Usually, the value that populates the From header field in requests
generated by a particular UA is pre-provisioned by the user or by the
administrators of the user's local domain. If a particular UA is
used by multiple users, it might have switchable profiles that
include a URI corresponding to the identity of the profiled user.
Recipients of requests can authenticate the originator of a request
in order to ascertain that they are who their From header field
claims they are (see Section 22 for more on authentication).
通常，UA生成的用于构造请求中From头域的值由用户或者用户本地域管理员预先配置。如果一个特定UA有多个用户使用，此UA可能具有可切换profile，profile通过URI对应用户标识。请求接收方可以对请求发起方进行身份验证，以确认From头域中声明的是谁（关于身份验证的更多信息请看22节）。
The From field MUST contain a new "tag" parameter, chosen by the UAC.
See Section 19.3 for details on choosing a tag.
From域必须包含UAC选择的新“tag”参数。19.3节论述选择tag的细节。
For further information on the From header field, see Section 20.20.
From头域的更多信息，参见20.20节。
Examples:
例子如下：
From: "Bob"
From: sip:[email protected];tag=887s
From: Anonymous
8.1.1.4 Call-ID
The Call-ID header field acts as a unique identifier to grouptogether a series of messages. It MUST be the same for all requests
and responses sent by either UA in a dialog. It SHOULD be the same
in each registration from a UA.
Call-ID头域作为唯一的表示，将一系列消息分为一组。在一个dialog中，所有请求好相应的call-id必须相同。UA的每一个注册消息的call-id都应当相同。
In a new request created by a UAC outside of any dialog, the Call-ID
header field MUST be selected by the UAC as a globally unique
identifier over space and time unless overridden by method-specific
behavior. All SIP UAs must have a means to guarantee that the Call-
ID header fields they produce will not be inadvertently generated by
any other UA. Note that when requests are retried after certain
failure responses that solicit an amendment to a request (for
example, a challenge for authentication), these retried requests are
not considered new requests, and therefore do not need new Call-ID
header fields; see Section 8.1.3.5.
UAC发送在dialog外的每一个新请求中，Call-ID头域不需有UAC设置为一个在时间和空间上全局唯一的标识，除非被特定的方法行为重写。所有的SIP UA必须有方式确保他们生成的Call-ID头域不会被其他UA无意地生成。注意，当请求在特定的错误响应（这些响应发起请求修改，比如一个鉴权challenge）后重试。这些重试请求不被认为是新的请求，所以需要新的call-ID头域。参见8.1.3.5节。
Use of cryptographically random identifiers (RFC 1750 [12]) in the
generation of Call-IDs is RECOMMENDED. Implementations MAY use the
form "localid@host". Call-IDs are case-sensitive and are simply
compared byte-by-byte.
推荐使用随机加密标识(RFC 1750 [12])生成Call-ID。 实现可以采用如下格式"localid@host"。Call-ID区分大小写，通过单个字节单个字节进行简单比较。
Using cryptographically random identifiers provides some
protection against session hijacking and reduces the likelihood of
unintentional Call-ID collisions.
使用随机加密标识提供一些对抗会话挟持的保护和减少无意的Call-ID冲突。
No provisioning or human interface is required for the selection of
the Call-ID header field value for a request.
请求的Call-ID头域值的选择不需要提供或者人机接口。
For further information on the Call-ID header field, see Section
20.8.
Call-ID头域的进一步信息，参见20.8节。
Example:
例子：
Call-ID: [email protected]
8.1.1.5 CSeq
The CSeq header field serves as a way to identify and ordertransactions. It consists of a sequence number and a method. The
method MUST match that of the request. For non-REGISTER requests
outside of a dialog, the sequence number value is arbitrary. The
sequence number value MUST be expressible as a 32-bit unsigned
integer and MUST be less than 2**31. As long as it follows the above
guidelines, a client may use any mechanism it would like to select
CSeq header field values.
CSeq头域提供标识和排序事务的方式。它包含一组数字和一个方法。方法必须和请求匹配。dialog外的非寄存器请求，其序列号是任意的。序列号值必须表示为32位无符号整数，并且必须小于2 ** 31。只要遵循上述准则，客户机就可以使用任何规则选择CSEQ头域值。
Section 12.2.1.1 discusses construction of the CSeq for requests
within a dialog.
12.2.1.1节讨论了dialog内请求CSeq的构造。
Example:
方法:
CSeq: 4711 INVITE
8.1.1.6 Max-Forwards
The Max-Forwards header field serves to limit the number of hops arequest can transit on the way to its destination. It consists of an
integer that is decremented by one at each hop. If the Max-Forwards
value reaches 0 before the request reaches its destination, it will
be rejected with a 483(Too Many Hops) error response.
Max-Forwards头域用于限制请求发往目的地的路上限制的跳数。它包含了一个数字，经过每一跳会减1.如果在到达目的地前，Max-Forwards变为0,将拒绝此请求，并发送回一个483（Too Many Hops）错误响应。
A UAC MUST insert a Max-Forwards header field into each request it
originates with a value that SHOULD be 70. This number was chosen to
be sufficiently large to guarantee that a request would not be
dropped in any SIP network when there were no loops, but not so large
as to consume proxy resources when a loop does occur. Lower values
should be used with caution and only in networks where topologies are
known by the UA.
UAC必须向其发出的每一个请求插入Max-Forwards头域，其值应该是70.该值被选择的足够大，以保证当没有回路时，在任何SIP网络中不会丢弃请求，但又不太大，以便在确实出现循环时不过多消耗代理资源。较低的值应谨慎使用，并仅在UA知道其拓扑的网络中使用。
8.1.1.7 Via
The Via header field indicates the transport used for the transactionand identifies the location where the response is to be sent. A Via
header field value is added only after the transport that will be
used to reach the next hop has been selected (which may involve the
usage of the procedures in [4]).
Via头域表明了事务的传输方式，以及指出响应将要发往的位置。只有下一跳的传输已经选定（可能会使用 [4]中的过程）后，才可以添加Via头域。
request. The protocol name and protocol version in the header field
MUST be SIP and 2.0, respectively. The Via header field value MUST
contain a branch parameter. This parameter is used to identify the
transaction created by that request. This parameter is used by both
the client and the server.
当UAC生成一个请求，必须在请求中插入Via。此头域的协议名和协议版本号必须分别是SIP和2.0. Via头域必须包含branch参数。 这个参数用于标识由那个请求建立的事务。此参数在客户端和服务端都被使用。
The branch parameter value MUST be unique across space and time for
all requests sent by the UA. The exceptions to this rule are CANCEL
and ACK for non-2xx responses. As discussed below, a CANCEL request
will have the same value of the branch parameter as the request it
cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx
response will also have the same branch ID as the INVITE whose
response it acknowledges.
此UA发出的所有请求中，branch 参数必须是时间和空间上唯一的。 此规则的例外是，非2XX响应的CANCEL和ACK。如下面论述，CANCEL请求的branch参数和其请求退出的request相同。像17.1.1.3中论述的，非2xx响应的请求可以和其应答的INVITE消息的branch参数相同。
The uniqueness property of the branch ID parameter, to facilitate
its use as a transaction ID, was not part of RFC 2543.
branch ID参数的唯一性，用于事务ID，不是RFC2543协议的一部分。
The branch ID inserted by an element compliant with this
specification MUST always begin with the characters "z9hG4bK". These
7 characters are used as a magic cookie (7 is deemed sufficient to
ensure that an older RFC 2543 implementation would not pick such a
value), so that servers receiving the request can determine that the
branch ID was constructed in the fashion described by this
specification (that is, globally unique). Beyond this requirement,
the precise format of the branch token is implementation-defined.
兼容本标准的元素添加的branch ID必须以"z9hG4bK"字符串开头。这七个字符被用作魔术cookie(7被认为足以确保较旧的RFC 2543实现不会选择这样的值),这样接收请求的服务端可以确定branch ID是按照本协议构造的（即，全局唯一）。除了这个需求外，branch token的详细格式是具体实现设计的。
The Via header maddr, ttl, and sent-by components will be set when
the request is processed by the transport layer (Section 18).
当传输层处理请求时（18节），Via 头域的maddr，ttl, 和 sent-by 部分将被设置。
Via processing for proxies is described in Section 16.6 Item 8 and
Section 16.7 Item 3.
代理对Via的处理在 16.6节第8项，和16.7节第3项中描述。
8.1.1.8 Contact
The Contact header field provides a SIP or SIPS URI that can be usedto contact that specific instance of the UA for subsequent requests.
The Contact header field MUST be present and contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog. For the methods defined in this specification, that includes
only the INVITE request. For these requests, the scope of the
Contact is global. That is, the Contact header field value contains
the URI at which the UA would like to receive requests, and this URI
MUST be valid even if used in subsequent requests outside of any
dialogs.
Contact头域提供SIP或SIPS URI，可以用于后续请求联系UA的特定实例。在可以建立dialog的请求中contact头域必须出现并明确包含一个SIP或SIPS URI。在协议中定义的方法只包含INVITE请求。在这些请求中，contact的范围是全局的。即， contact头域值包含UA期望接收请求的URI。这个URI在随后任何dialog之外的请求总使用也是有效的。
If the Request-URI or top Route header field value contains a SIPS
URI, the Contact header field MUST contain a SIPS URI as well.
如果请求URI或者顶部Route头域值包含SIPS URI，Contact头域也要包含SIP URI。
For further information on the Contact header field, see Section
20.10.
更多Contact头域的信息，参见20.10节。
8.1.1.9 Supported and Require 支持和要求
If the UAC supports extensions to SIP that can be applied by theserver to the response, the UAC SHOULD include a Supported header
field in the request listing the option tags (Section 19.2) for those
extensions.
如果UAC支持一些服务端响应可以应用的SIP扩展，UAC应该在请求中包含一个Supported 头域，列举这些扩展的option tags（19.2节）。
The option tags listed MUST only refer to extensions defined in
standards-track RFCs. This is to prevent servers from insisting that
clients implement non-standard, vendor-defined features in order to
receive service. Extensions defined by experimental and
informational RFCs are explicitly excluded from usage with the
Supported header field in a request, since they too are often used to
document vendor-defined extensions.
列举的扩展option tag必须定义在standards-track RFC中。这可以防止服务端要求客户端为了获取服务而实现一些不标准的、供应商定义特性。在experimental and informational RFCs中定义的扩展被明确排除在请求的Supported头域中，因为他们经常被用于常常定义的扩展。
If the UAC wishes to insist that a UAS understand an extension that
the UAC will apply to the request in order to process the request, it
MUST insert a Require header field into the request listing the
option tag for that extension. If the UAC wishes to apply an
extension to the request and insist that any proxies that are
traversed understand that extension, it MUST insert a Proxy-Require
header field into the request listing the option tag for that
extension.
如果UAC希望要求UAS处理请求时，理解某个UAC将要应用于请求的扩展，UAC必须在请求中插入Require头域来列举扩展的option tag。如果UAC希望请求中应用一个扩展，并且要求通过的代理理解这个扩展，UAC必须将那个扩展的option tag 插入Proxy-Require头域的列表。
As with the Supported header field, the option tags in the Require
and Proxy-Require header fields MUST only refer to extensions defined
in standards-track RFCs.
和Supported头域一样，Require和 Proxy-Require 头域只能包含 standards-track RFCs中定义的扩展。
8.1.1.10 Additional Message Components 附加消息组件
After a new request has been created, and the header fields describedabove have been properly constructed, any additional optional header
fields are added, as are any header fields specific to the method.
一个请求生成，上面论述的头域已经被合适的构造。后面添加任何附加可选头域都和添加的任何特定方法的头域相同。
SIP requests MAY contain a MIME-encoded message-body. Regardless of
the type of body that a request contains, certain header fields must
be formulated to characterize the contents of the body. For further
information on these header fields, see Sections 20.11 through 20.15.
SIP请求可以包含MIME-encoded的消息体。无论请求包含的消息体类型，必须设定特定的头域以表征消息体内容。这些头域的进一步信息，参见20.11到20.15节。
8.1.2 Sending the Request 发送消息
The destination for the request is then computed. Unless there is
local policy specifying otherwise, the destination MUST be determined
by applying the DNS procedures described in [4] as follows. If the
first element in the route set indicated a strict router (resulting
in forming the request as described in Section 12.2.1.1), the
procedures MUST be applied to the Request-URI of the request.
Otherwise, the procedures are applied to the first Route header field
value in the request (if one exists), or to the request's Request-URI
if there is no Route header field present. These procedures yield an
ordered set of address, port, and transports to attempt. Independent
of which URI is used as input to the procedures of [4], if the
Request-URI specifies a SIPS resource, the UAC MUST follow the
procedures of [4] as if the input URI were a SIPS URI.
然后计算请求的目的。除非本地策略另有指定，目的地必须按照【4】中规定的DNS操作流程决定。如果路由集的第一个元素是一个严格路由（按照12.2.1.1节的论述构造消息。），那么操作流程必须应用于请求的Request-URI。否则操作流程应用于请求的第一个路由头域值（如果存在一个），或者应用于请求的Request-URI（如果没有路由头域存在）。这些操作流程将尝试一组地址、端口、传输方式的有序集合。无论【4】中操作流程的输入是什么URI，如果Request-URI指定的是SIPS 资源，UAC必须按照【4】输入URI是SIPS URI的操作流程工作。
Local policy MAY specify an alternate set of destinations to attempt.
If the Request-URI contains a SIPS URI, any alternate destinations
MUST be contacted with TLS. Beyond that, there are no restrictions
on the alternate destinations if the request contains no Route header
field. This provides a simple alternative to a pre-existing route
set as a way to specify an outbound proxy. However, that approach
for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
route set with a single URI SHOULD be used instead. If the request
contains a Route header field, the request SHOULD be sent to the
locations derived from its topmost value, but MAY be sent to any
server that the UA is certain will honor the Route and Request-URI
policies specified in this document (as opposed to those in RFC
2543). In particular, a UAC configured with an outbound proxy SHOULD
attempt to send the request to the location indicated in the first
Route header field value instead of adopting the policy of sending
all messages to the outbound proxy.
本地路由可以定义试探的备选目的地。如果Request-URI 包含SIPS URI，任何备选目的地必须通过TLS沟通。除此之外，如果请求不包含Route头域，对备选目的地没有限制。这为预先指定的路由设置提供了一种简单的替代方法，即指定出站代理。但是，不建议配置出站代理；应该使用一个单独URI的预先配置路由集。如果请求包含一个Route头域，应当将请求发往其顶部值导出的地点。但是，如果UA确认可以遵循本文档定义的Route和Request-URI策略，也可发往任何服务器（和RFC2543相反）。特别地，配置有出站代理的UAC应尝试将请求发送到第一路由标头字段值中指示的位置，而不是采用将所有消息发送到出站代理的策略。
This ensures that outbound proxies that do not add Record-Route
header field values will drop out of the path of subsequent
requests. It allows endpoints that cannot resolve the first Route
URI to delegate that task to an outbound proxy.
这确保不添加记录路由头字段值的出站代理将退出后续请求的路径。它允许不能解析第一路由URI的端点将该任务委托给出站代理。
The UAC SHOULD follow the procedures defined in [4] for stateful
elements, trying each address until a server is contacted. Each try
constitutes a new transaction, and therefore each carries a different
topmost Via header field value with a new branch parameter.
Furthermore, the transport value in the Via header field is set to
whatever transport was determined for the target server.
UAC应该遵循【4】中对有状态元素定义的操作流程，尝试每一个地址，知道联系到一个服务器。每一个尝试构成一个新的事务，因此每个请求都携带一个不同branch参数的不同顶层Via头域。此外，在Via报头字段中的传输值被设置为为目标服务器确定的任何传输方式。
8.1.3 Processing Responses 响应流程
Responses are first processed by the transport layer and then passed
up to the transaction layer. The transaction layer performs its
processing and then passes the response up to the TU. The majority
of response processing in the TU is method specific. However, there
are some general behaviors independent of the method.
响应首先被传输层处理，然后传递到上层的事务层。事务层执行完他的操作，然后将响应上传至TU。TU处理响应的主要流程是针对方法的。不过，有一些通用的行为是和方法无关的。
8.1.3.1 Transaction Layer Errors 事务层错误
In some cases, the response returned by the transaction layer willnot be a SIP message, but rather a transaction layer error. When a
timeout error is received from the transaction layer, it MUST be
treated as if a 408 (Request Timeout) status code has been received.
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.
有些情况下，事务层返回的响应不是SIP消息，而是事务层错误。当从事务层收到超时错误，这个错误必须和收到408（请求超时）状态码一样处理。如果事务层上报了严重传输错误（通常是UDP的严重ICMP错误，或者TCP的链接错误），这种情况必须和收到503（服务不可达）状态码一样处理。
8.1.3.2 Unrecognized Responses 无法识别响应
A UAC MUST treat any final response it does not recognize as beingequivalent to the x00 response code of that class, and MUST be able
to process the x00 response code for all classes. For example, if a
UAC receives an unrecognized response code of 431, it can safely
assume that there was something wrong with its request and treat the
response as if it had received a 400 (Bad Request) response code. A
UAC MUST treat any provisional response different than 100 that it
does not recognize as 183 (Session Progress). A UAC MUST be able to
process 100 and 183 responses.
UAC需要将其无法识别的 最终响应当做同类的x00响应码处理。比如，如果UAC收到了无法识别的431响应码，它可以安全的认为他的请求除了一些错误，并将这个响应当做400（错误请求）响应码处理。UAC必须将任何其无法识别的 不同于100的临时响应都当做183（会话处理）处理。UAC必须可以处理100和183响应。
8.1.3.3 Vias
If more than one Via header field value is present in a response, theUAC SHOULD discard the message.
如果超过一个Via头域值出现在响应中，UAC必须丢弃这个消息。
The presence of additional Via header field values that precede
the originator of the request suggests that the message was
misrouted or possibly corrupted.
请求的发起方遇到多余的Via头域值的出现，意味着消息被错误路由或者可能冲突了。
8.1.3.4 Processing 3xx Responses 3XX响应的处理
Upon receipt of a redirection response (for example, a 301 responsestatus code), clients SHOULD use the URI(s) in the Contact header
field to formulate one or more new requests based on the redirected
request. This process is similar to that of a proxy recursing on a
3xx class response as detailed in Sections 16.5 and 16.6. A client
starts with an initial target set containing exactly one URI, the
Request-URI of the original request. If a client wishes to formulate
new requests based on a 3xx class response to that request, it places
the URIs to try into the target set. Subject to the restrictions in
this specification, a client can choose which Contact URIs it places
into the target set. As with proxy recursion, a client processing
3xx class responses MUST NOT add any given URI to the target set more
than once. If the original request had a SIPS URI in the Request-
URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD
inform the user of the redirection to an insecure URI.
当收到重定向响应（比如，301响应状态码），客户端应当基于重定向请求，使用 Contact头域中的URI生成一个或多个新的请求。这一过程和16.5与16.6节中详细论述的操作类似。16.5与16.6节中详细论述了代理递归对3XX类响应执行的操作。客户端从初始目标集开始，该目标集正好包含一个URI，即原始请求的 Request-URI。如果客户端希望根据对该请求的3XX类响应来制定新请求，则将URIs放置到目标集中。根据本规范中，客户端可以选择放置哪个Contact URI到目标集中。和代理递归类似，客户端处理3XX类响应时，一个给定URI至多只能放到目标中一次。如果初始请求在Request-URI中包含SIPS URI，客户端可以选择递归到一个非SIPS URI，但是应该提示用户，重定向到不安全的URI。
Any new request may receive 3xx responses themselves containing
the original URI as a contact. Two locations can be configured to
redirect to each other. Placing any given URI in the target set
only once prevents infinite redirection loops.
任何新情求可能收到包含初始URI作为contact的3XX响应。两个地址可以被配置彼此重定向。任何给定URI只设置到目标集一次可以避免无穷的重定向回环。
As the target set grows, the client MAY generate new requests to the
URIs in any order. A common mechanism is to order the set by the "q"
parameter value from the Contact header field value. Requests to the
URIs MAY be generated serially or in parallel. One approach is to
process groups of decreasing q-values serially and process the URIs
in each q-value group in parallel. Another is to perform only serial
processing in decreasing q-value order, arbitrarily choosing between
contacts of equal q-value.
随着目标集增长，客户端可以针对这些URI以任何顺序生成新请求。一个通用机制是按照Contact头域值中的“q”参数排序。发往这些URI的请求可以串行或并行生成。一种方法，串行处理递减q-value和其对应的组，每一个q-value 组的URIs并行处理。另一个方案是仅仅串行处理降序排列的q-value，任意选择等价q-value间的contact。
If contacting an address in the list results in a failure, as defined
in the next paragraph, the element moves to the next address in the
list, until the list is exhausted. If the list is exhausted, then
the request has failed.
如果联系列表中的某个地址，产生一个下个段落中定义的错误，元素移动到列表中的下个地址，知道列表被遍历。如果遍历完列表，那么这个请求就失败了。
Failures SHOULD be detected through failure response codes (codes
greater than 399); for network errors the client transaction will
report any transport layer failures to the transaction user. Note
that some response codes (detailed in 8.1.3.5) indicate that the
request can be retried; requests that are reattempted should not be
considered failures.
应该通过失败响应码（大于399的码）检测失败。对于网络错误，客户端事务将上报任何传输层错误至事务用户。注意，一些响应码（8.1.3.5中详细描述）表示请求可以重试；重试的请求不应当认为失败。
When a failure for a particular contact address is received, the
client SHOULD try the next contact address. This will involve
creating a new client transaction to deliver a new request.
当收到至一个特定contact 地址的失败，客户端应当尝试下一个contact地址。这将包含建立一个发送新情求的新客户事务。
In order to create a request based on a contact address in a 3xx
response, a UAC MUST copy the entire URI from the target set into the
Request-URI, except for the "method-param" and "header" URI
parameters (see Section 19.1.1 for a definition of these parameters).
It uses the "header" parameters to create header field values for the
new request, overwriting header field values associated with the
redirected request in accordance with the guidelines in Section
19.1.5.
为了基于一个3xx响应中的contact地址建立请求，UAC必须从目标集中拷贝整个URI至Request-URI,除了名为"method-param" 和 "header" 的URI参数(这些参数的定义参见19.1.1节)。它使用"header" 参数来生成新情求的头域值，根据19.1.5节中的准则重写与重定向请求相关联的标头字段值。
Note that in some instances, header fields that have been
communicated in the contact address may instead append to existing
request header fields in the original redirected request. As a
general rule, if the header field can accept a comma-separated list
of values, then the new header field value MAY be appended to any
existing values in the original redirected request. If the header
field does not accept multiple values, the value in the original
redirected request MAY be overwritten by the header field value
communicated in the contact address. For example, if a contact
address is returned with the following value:
请注意，在某些情况下，在contact地址中已经通讯过的头域可以附加到原始被重定向请求的现有请求头域中。作为一个通用规则，如果头域可以接受分好分割的列表，那么新的头域值可以附加到原始重定向请求的任何一个现有值后。如果头域不支持多个值，原始被重定向的请求中的值将被通讯的contact地址中的头域值重写。比如，如果一个头域值返回了如下值：
sip:user@host?Subject=foo&Call-Info=
Then any Subject header field in the original redirected request is
overwritten, but the HTTP URL is merely appended to any existing
Call-Info header field values.
那么原始被重定向的请求的SubjectUI头域将被重写，但是HTTP URL则只是添加到任何存在的Call-Info头域值后面。
It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example.
建议UAC重用和原始被重定向请求中 To, From,和 Call-ID相同的值，不过UAC也能选择新请求更新Call-ID头域值。Finally, once the new request has been constructed, it is sent using
a new client transaction, and therefore MUST have a new branch ID in
the top Via field as discussed in Section 8.1.1.7.
最后，一旦新的请求构造出来，新的客户端事务将发出此请求。因此，像 8.1.1.7节论述的那样，新请求必须在顶层Via域中有一个新的branch ID。