RFC3261: SIP:19.1.1 SIP和SIPS URI组件

19.1.1 SIP and SIPS URI Components
19.1.1 SIP和SIPS URI组件

   The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto URL, allowing the specification of SIP request-header fields and the SIP message-body.  This makes it possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or in an email message.  The formal syntax for a SIP or SIPS URI is presented in Section 25.  Its general form, in the case of a SIP URI, is:

​“sip:”和“sips:”方案遵循RFC 2396[5]中的指导方针。它们使用类似于mailtoURL的形式，允许指定SIP请求报头字段和SIP消息体。这使得可以通过在网页或电子邮件中使用URI来指定会话的主题、媒体类型或紧急性。第25节介绍了SIP或SIPS URI的形式语法。在SIP URI的情况下，其一般形式是：

      sip:user:password@host:port;uri-parameters?headers

   The format for a SIPS URI is the same, except that the scheme is "sips" instead of sip.  These tokens, and some of the tokens in their expansions, have the following meanings:

SIPS URI的格式是相同的，只是方案是“SIPS”而不是sip。这些令牌以及其扩展中的一些令牌具有以下含义：

      user: The identifier of a particular resource at the host being addressed.  The term "host" in this context frequently refers to a domain.  The "userinfo" of a URI consists of this user field, the password field, and the @ sign following them.  The userinfo part of a URI is optional and MAY be absent when the destination host does not have a notion of users or when the host itself is the resource being identified.  If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty.

user：正在寻址的主机上的特定资源的标识符。在此上下文中，术语“host”经常指域。URI的“userinfo”由这个用户字段、密码字段和后面的@符号组成。URI的userinfo部分是可选的，当目标主机没有用户的概念时，或者当主机本身是要标识的资源时，它可能不存在。如果@符号存在于SIP或SIPS URI中，则用户字段不得为空。

         If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephone-subscriber field defined in RFC 2806 [9] MAY be used to populate the user field.  There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs described in Section 19.1.2.
​
如果被寻址的主机可以处理电话号码，例如，互联网电话网关，则可以使用RFC 2806[9]中定义的电话用户字段来填充用户字段。在第19.1.2节中描述了对SIP和SIPS URI中的电话用户字段进行编码的特殊转义规则。

      password: A password associated with the user.  While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used.  For instance, transporting a PIN number in this field exposes the PIN.

password：与用户关联的密码。虽然SIP和SIPS URI语法允许出现此字段，但不建议使用它，因为在几乎所有使用过它的情况下，以明文形式传递身份验证信息（如URI）都被证明是一种安全风险。例如，在此字段中传输PIN号会暴露PIN。

         Note that the password field is just an extension of the user portion.  Implementations not wishing to give special significance to the password portion of the field MAY simply treat "user:password" as a single string.

请注意，密码字段只是用户部分的扩展。不希望赋予字段的密码部分特殊意义的实现可以简单地将“user:password”视为单个字符串。

      host: The host providing the SIP resource.  The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address.  Using the fully-qualified domain name form is RECOMMENDED whenever possible.

host：提供SIP资源的主机。主机部分包含完全限定的域名或数字IPv4或IPv6地址。建议尽可能使用完全限定的域名表格。

      port: The port number where the request is to be sent.

port：发送请求的端口号。

      URI parameters: Parameters affecting a request constructed from the URI.

URI参数：影响根据URI构造的请求的参数。

         URI parameters are added after the hostport component and are separated by semi-colons.

URI参数添加在hostport组件之后，并用分号分隔。

         URI parameters take the form:

URI参数的形式如下：

            parameter-name "=" parameter-value

         Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-name MUST NOT appear more than once.

即使URI中可以包括任意数量的URI参数，任何给定的参数名称也不得出现多次。

         This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters.

这种可扩展机制包括传输、maddr、ttl、用户、方法和lr参数。

         The transport parameter determines the transport mechanism to be used for sending SIP messages, as specified in [4].  SIP can use any network transport protocol.  Parameter names are defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP (RFC 2960 [16]).  For a SIPS URI, the transport parameter MUST indicate a reliable transport.

​传输参数确定用于发送SIP消息的传输机制，如[4]中所述。SIP可以使用任何网络传输协议。为UDP（RFC 768[14]）、TCP（RFC 761[15]）和SCTP（RFC 2960[16]）定义了参数名称。对于SIPS URI，传输参数必须指示可靠的传输。

         The maddr parameter indicates the server address to be contacted for this user, overriding any address derived from the host field.  When an maddr parameter is present, the port and transport components of the URI apply to the address indicated in the maddr parameter value.  [4] describes the proper interpretation of the transport, maddr, and hostport in order to obtain the destination address, port, and transport for sending a request.

​maddr参数指示该用户要联系的服务端地址，覆盖从主机字段派生的任何地址。当存在maddr参数时，URI的端口和传输组件应用于maddr参数值中指示的地址。[4] 描述了传输、maddr和hostport的正确解释，以便获得发送请求的目的地地址、端口和传输。
​
         The maddr field has been used as a simple form of loose source routing.  It allows a URI to specify a proxy that must be traversed en-route to the destination.  Continuing to use the maddr parameter this way is strongly discouraged (the mechanisms that enable it are deprecated).  Implementations should instead use the Route mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1).  This provides a full URI to describe the node to be traversed.

​madder字段已被用作松散源路由的一种简单形式。它允许URI指定在到达目的地的途中必须遍历的代理。强烈反对以这种方式继续使用maddr参数（不赞成使用启用它的机制）。实现应该使用本文档中描述的路由机制，如有必要，建立预先存在的路由集（请参见第8.1.1.1节）。这提供了一个完整的URI来描述要遍历的节点。

         The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP.  For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, the following URI would be used:

ttl参数确定UDP多播数据包的生存时间值，并且仅当maddr是多播地址并且传输协议是UDP时才必须使用。例如，指定对的调用alice@atlanta.com使用ttl为15的239.255.255.1多播，将使用以下URI：

            sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15

         The set of valid telephone-subscriber strings is a subset of valid user strings.  The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers.  If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present.  Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it.

有效电话用户字符串的集合是有效用户字符串的子集。用户URI参数的存在是为了区分电话号码和看起来像电话号码的用户名。如果用户字符串包含一个格式化为电话用户的电话号码，则应显示用户参数值“phone”。即使没有这个参数，如果用户名的名称空间的本地限制允许，SIP和SIPS URI的接收者也可以将pre-@部分解释为电话号码。

         The method of the SIP request constructed from the URI can be specified with the method parameter.

根据URI构建的SIP请求的方法可以通过方法参数指定。

         The lr parameter, when present, indicates that the element responsible for this resource implements the routing mechanisms specified in this document.  This parameter will be used in the URIs proxies place into Record-Route header field values, and may appear in the URIs in a pre-existing route set.

lr参数（如果存在）表示负责此资源的元素实现本文档中指定的路由机制。此参数将在放入记录路由报头字段值的URI代理中使用，并且可能出现在预先存在的路由集中的URI中。

         This parameter is used to achieve backwards compatibility with systems implementing the strict-routing mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05.  An element preparing to send a request based on a URI not containing this parameter can assume the receiving element implements strict-routing and reformat the message to preserve the information in the Request-URI.

​此参数用于实现与实现RFC 2543和rfc2543bis草案（直到bis-05）的严格路由机制的系统的向后兼容性。准备基于不包含此参数的URI发送请求的元素可以假设接收元素实现严格的路由并重新格式化消息以保留请求URI中的信息。

         Since the uri-parameter mechanism is extensible, SIP elements MUST silently ignore any uri-parameters that they do not understand.

由于uri参数机制是可扩展的，因此SIP元素必须静默地忽略他们不理解的任何uri参数。

      Headers: Header fields to be included in a request constructed from the URI.

Headers：根据URI构造的请求中要包含的报头字段。

         Headers fields in the SIP request can be specified with the "?" mechanism within a URI.  The header names and values are encoded in ampersand separated hname = hvalue pairs.  The special hname "body" indicates that the associated hvalue is the message-body of the SIP request.

SIP请求中的报头字段可以使用URI中的“？”机制指定。报头名称和值以与号和分隔的hname=hvlue对进行编码。特殊的hname“body”表示关联的hvlue是SIP请求的消息体。

   Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI appears.  The external column describes URIs appearing anywhere outside of a SIP message, for instance on a web page or business card.  Entries marked "m" are mandatory, those marked "o" are optional, and those marked "-" are not allowed. Elements processing URIs SHOULD ignore any disallowed components if they are present.  The second column indicates the default value of an optional element if it is not present.  "--" indicates that the element is either not optional, or has no default value.

表1基于URI出现的上下文总结了SIP和SIPS URI组件的使用。外部列描述了出现在SIP消息之外的任何位置的URI，例如在网页或名片上。标记为“m”的条目为必填项，标记为“o”的条目是可选项，不允许标记为“-”的条目。处理URI的元素应该忽略任何不允许的组件（如果存在）。第二列指示可选元素的默认值（如果不存在）。“--”表示该元素不是可选的，或者没有默认值。

   URIs in Contact header fields have different restrictions depending on the context in which the header field appears.  One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) response).  The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, and 3xx class responses to any method).

“Contact”报头字段中的URI有不同的限制，具体取决于报字段出现的上下文。一组应用于建立和维护对话的消息（INVITE及其200（OK）响应）。另一种适用于注册和重定向消息（REGISTER，其200（OK）响应，以及对任何方法的3xx类响应）。