RFC3261: SIP:28.1 主要功能变化

28.1 Major Functional Changes
28.1 主要功能变化

   o  When a UAC wishes to terminate a call before it has been answered, it sends CANCEL.  If the original INVITE still returns a 2xx, the UAC then sends BYE.  BYE can only be sent on an existing call leg (now called a dialog in this RFC), whereas it could be sent at any time in RFC 2543.

​o当UAC希望在应答之前终止呼叫时，它会发送CANCEL。如果原始INVITE仍然返回2xx，则UAC发送BYE。BYE只能在现有的调用支路上发送（现在在这个RFC中称为对话），而在RFC 2543中它可以在任何时候发送。

   o  The SIP BNF was converted to be RFC 2234 compliant.

​o SIP BNF已转换为符合RFC 2234。

   o  SIP URL BNF was made more general, allowing a greater set of characters in the user part.  Furthermore, comparison rules were simplified to be primarily case-insensitive, and detailed handling of comparison in the presence of parameters was described.  The most substantial change is that a URI with a parameter with the default value does not match a URI without that parameter.

o SIP URL BNF变得更加通用，允许在用户部分使用更多的字符集。此外，比较规则被简化为主要不区分大小写，并描述了在存在参数的情况下对比较的详细处理。最重要的变化是，带有默认值参数的URI与没有该参数的URI不匹配。

   o  Removed Via hiding.  It had serious trust issues, since it relied on the next hop to perform the obfuscation process.  Instead, Via hiding can be done as a local implementation choice in stateful proxies, and thus is no longer documented.

oVia隐藏方式移除。它存在严重的信任问题，因为它依赖下一跳来执行模糊处理过程。相反，Via隐藏可以作为有状态代理中的本地实现选择，因此不再有文档记录。

   o  In RFC 2543, CANCEL and INVITE transactions were intermingled. They are separated now.  When a user sends an INVITE and then a CANCEL, the INVITE transaction still terminates normally.  A UAS needs to respond to the original INVITE request with a 487 response.

​o在RFC 2543中，CANCEL和INVITE事务混合在一起。他们现在分开了。当用户发送INVITE，然后发送CANCEL时，INVITE事务仍然正常终止。UAS需要用487响应来响应原始INVITE请求。

   o  Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received.  That is disallowed here.  The original INVITE needs a response.

​o同样，CANCEL和BYE事务也混杂在一起；RFC 2543允许UAS在接收到BYE时不发送对INVITE的响应。这是不允许的。原始INVITE需要响应。

   o  In RFC 2543, UAs needed to support only UDP.  In this RFC, UAs need to support both UDP and TCP.

​o在RFC 2543中，UA只需要支持UDP。在这个RFC中，UA需要同时支持UDP和TCP。

   o  In RFC 2543, a forking proxy only passed up one challenge from downstream elements in the event of multiple challenges.  In this RFC, proxies are supposed to collect all challenges and place them into the forwarded response.

​o在RFC 2543中，在发生多个质疑的情况下，分叉代理只传递来自下游元素的一个挑战。在这个RFC中，代理应该收集所有质疑并将它们放入转发的响应中。

   o  In Digest credentials, the URI needs to be quoted; this is unclear from RFC 2617 and RFC 2069 which are both inconsistent on it.

​o在摘要式凭据中，需要引用URI；这从RFC 2617和RFC 2069中是不清楚的，这两个版本都不一致。

   o  SDP processing has been split off into a separate specification [13], and more fully specified as a formal offer/answer exchange process that is effectively tunneled through SIP.  SDP is allowed in INVITE/200 or 200/ACK for baseline SIP implementations; RFC 2543 alluded to the ability to use it in INVITE, 200, and ACK in a single transaction, but this was not well specified.  More complex SDP usages are allowed in extensions.

​o SDP处理已被拆分为一个单独的规范[13]，并被更全面地指定为通过SIP有效隧道传输的正式offer/answer交换过程。对于基线SIP实现，在INVITE/200或200/ACK中允许SDP；RFC 2543暗示了在单个事务中的INVITE、200和ACK中使用它的能力，但这一点没有得到很好的说明。扩展中允许使用更复杂的SDP。

   o  Added full support for IPv6 in URIs and in the Via header field. Support for IPv6 in Via has required that its header field parameters allow the square bracket and colon characters.  These characters were previously not permitted.  In theory, this could cause interop problems with older implementations.  However, we have observed that most implementations accept any non-control ASCII character in these parameters.

o在URI和Via头字段中添加了对IPv6的完全支持。Via对IPv6的支持要求其标头字段参数允许使用方括号和冒号字符。以前不允许使用这些字符。理论上，这可能会导致旧实现的互操作问题。然而，我们已经观察到，大多数实现都接受这些参数中的任何非控制ASCII字符。

   o  DNS SRV procedure is now documented in a separate specification [4].  This procedure uses both SRV and NAPTR resource records and no longer combines data from across SRV records as described in RFC 2543.

​o DNS SRV程序现在记录在单独的规范[4]中。此过程同时使用SRV和NAPTR资源记录，并且不再像RFC 2543中所描述的那样组合来自各个SRV记录的数据。

   o  Loop detection has been made optional, supplanted by a mandatory usage of Max-Forwards.  The loop detection procedure in RFC 2543 had a serious bug which would report "spirals" as an error condition when it was not.  The optional loop detection procedure is more fully and correctly specified here.

​o循环检测已成为可选项，取而代之的是强制使用Max-Forwards。RFC 2543中的循环检测过程有一个严重的错误，当它不是时，会将“螺旋”报告为错误条件。此处更全面、更正确地规定了可选环路检测程序。

   o  Usage of tags is now mandatory (they were optional in RFC 2543), as they are now the fundamental building blocks of dialog identification.
​
o标签的使用现在是强制性的（在RFC 2543中是可选的），因为它们现在是对话标识的基本构建块。

   o  Added the Supported header field, allowing for clients to indicate what extensions are supported to a server, which can apply those extensions to the response, and indicate their usage with a Require in the response.

o添加了Supported报头字段，允许客户端指示服务器支持哪些扩展，服务器可以将这些扩展应用于响应，并在响应中用Require指示其使用情况。

   o  Extension parameters were missing from the BNF for several header fields, and they have been added.

o BNF中缺少几个报头字段的扩展参数，已添加这些参数。

   o  Handling of Route and Record-Route construction was very underspecified in RFC 2543, and also not the right approach.  It has been substantially reworked in this specification (and made vastly simpler), and this is arguably the largest change. Backwards compatibility is still provided for deployments that do not use "pre-loaded routes", where the initial request has a set of Route header field values obtained in some way outside of Record-Route.  In those situations, the new mechanism is not interoperable.

​o在RFC 2543中，对路由和记录路由构造的处理没有得到充分说明，也不是正确的方法。在本规范中对其进行了实质性的修改（并使其变得更加简单），这可以说是最大的变化。对于不使用“预加载路由”的部署，仍然提供了向后兼容性，其中初始请求具有一组在记录路由之外以某种方式获得的Route报头字段值。在这些情况下，新机制是不可互操作的。

   o  In RFC 2543, lines in a message could be terminated with CR, LF, or CRLF.  This specification only allows CRLF.

​o在RFC 2543中，消息中的行可以用CR、LF或CRLF终止。本规范仅允许CRLF。

   o  Usage of Route in CANCEL and ACK was not well defined in RFC 2543. It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values.  ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses.
​
o在RFC 2543中没有很好地定义CANCEL和ACK中路由的使用。它现在已被明确规定；如果一个请求有一个Route报头字段，则其针对该请求的非2xx响应的CANCEL或ACK需要携带相同的Route报头域值。2xx响应的ACK使用从2xx响应记录路由中学习到的路由值。

   o  RFC 2543 allowed multiple requests in a single UDP packet.  This usage has been removed.

​o RFC 2543允许在单个UDP数据包中进行多个请求。此用法已被删除。

   o  Usage of absolute time in the Expires header field and parameter has been removed.  It caused interoperability problems in elements that were not time synchronized, a common occurrence.  Relative times are used instead.

o Expires报头字段和参数中绝对时间的使用已被删除。它在没有时间同步的元素中导致互操作性问题，这是一种常见的情况。而是使用相对时间。

   o  The branch parameter of the Via header field value is now mandatory for all elements to use.  It now plays the role of a unique transaction identifier.  This avoids the complex and bug-laden transaction identification rules from RFC 2543.  A magic cookie is used in the parameter value to determine if the previous hop has made the parameter globally unique, and comparison falls back to the old rules when it is not present.  Thus, interoperability is assured.

​o Via报头字段值的分支参数现在是所有元素必须使用的参数。它现在扮演一个唯一的事务标识符的角色。这避免了RFC 2543中复杂且充满错误的事务标识规则。在参数值中使用魔术cookie来确定上一跳是否使参数全局唯一，当不存在时，比较将返回到旧规则。因此，互操作性得到了保证。

   o  In RFC 2543, closure of a TCP connection was made equivalent to a CANCEL.  This was nearly impossible to implement (and wrong) for TCP connections between proxies.  This has been eliminated, so that there is no coupling between TCP connection state and SIP processing.

​o在RFC 2543中，TCP连接的关闭等同于CANCEL。对于代理之间的TCP连接，这几乎是不可能实现的（也是错误的）。这一点已经消除，因此TCP连接状态和SIP处理之间没有耦合。

   o  RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress.  That is now specified here.  It is allowed for non-INVITE requests, disallowed for INVITE.

​o RFC 2543对UA是否可以在另一个事务正在进行时向对等方发起新事务保持沉默。现在在这里具体说明。它允许用于非INVITE请求，不允许用于INVITE。

   o  PGP was removed.  It was not sufficiently specified, and not compatible with the more complete PGP MIME.  It was replaced with S/MIME.

o PGP被移除。它没有得到充分的指定，并且与更完整的PGP MIME不兼容。它被S/MIME所取代。

   o  Added the "sips" URI scheme for end-to-end TLS.  This scheme is not backwards compatible with RFC 2543.  Existing elements that receive a request with a SIPS URI scheme in the Request-URI will likely reject the request.  This is actually a feature; it ensures that a call to a SIPS URI is only delivered if all path hops can be secured.

​o为端到端TLS添加了“sips”URI方案。此方案与RFC 2543不向后兼容。接收到Request-URI中具有SIPS URI方案的请求的现有元素可能会拒绝该请求。这实际上是一个特点；它确保只有在所有路径跳都可以得到保护的情况下才传递对SIPS URI的调用。

   o  Additional security features were added with TLS, and these are described in a much larger and complete security considerations section.

o TLS增加了额外的安全功能，这些功能在更大、更完整的安全注意事项部分进行了描述。

   o  In RFC 2543, a proxy was not required to forward provisional responses from 101 to 199 upstream.  This was changed to MUST. This is important, since many subsequent features depend on delivery of all provisional responses from 101 to 199.

​o在RFC 2543中，不需要代理将临时响应从101转发到199上游。这已更改为MUST。这一点很重要，因为许多后续特征取决于从101到199的所有临时响应的传递。

   o  Little was said about the 503 response code in RFC 2543.  It has since found substantial use in indicating failure or overload conditions in proxies.  This requires somewhat special treatment. Specifically, receipt of a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup.  Also, 503 response is only forwarded upstream by a proxy under certain conditions.

​o关于RFC 2543中的503响应代码，几乎没有提及。自那以后，它在指示代理中的故障或过载条件方面得到了实质性的应用。这需要一些特殊的处理。具体地，503的接收应当触发在DNS SRV查找的结果中联系下一个元素的尝试。此外，503响应仅在某些条件下由代理向上游转发。

   o  RFC 2543 defined, but did no sufficiently specify, a mechanism for UA authentication of a server.  That has been removed.  Instead, the mutual authentication procedures of RFC 2617 are allowed.

​o RFC 2543定义了服务器的UA身份验证机制，但没有充分规定。已删除。相反，RFC 2617的相互认证过程是允许的。

   o  A UA cannot send a BYE for a call until it has received an ACK for the initial INVITE.  This was allowed in RFC 2543 but leads to a potential race condition.

​o UA在收到初始INVITE的ACK之前，不能发送呼叫的BYE。这在RFC 2543中是允许的，但会导致潜在的竞争条件。

   o  A UA or proxy cannot send CANCEL for a transaction until it gets a provisional response for the request.  This was allowed in RFC 2543 but leads to potential race conditions.

​o UA或代理在收到请求的临时响应之前，不能发送事务的CANCEL。这在RFC 2543中是允许的，但会导致潜在的竞争条件。

   o  The action parameter in registrations has been deprecated.  It was insufficient for any useful services, and caused conflicts when application processing was applied in proxies.

o注册中的操作参数已被弃用。它不足以提供任何有用的服务，并且在代理中应用应用程序处理时会导致冲突。

   o  RFC 2543 had a number of special cases for multicast.  For example, certain responses were suppressed, timers were adjusted, and so on.  Multicast now plays a more limited role, and the protocol operation is unaffected by usage of multicast as opposed to unicast.  The limitations as a result of that are documented.

​o RFC 2543对多播有许多特殊情况。例如，某些响应被抑制，定时器被调整，等等。多播现在发挥的作用更加有限，而且与单播相比，协议操作不受多播使用的影响。由此产生的局限性已记录在案。

   o  Basic authentication has been removed entirely and its usage forbidden.

o基本身份验证已被完全删除，禁止使用。

   o  Proxies no longer forward a 6xx immediately on receiving it. Instead, they CANCEL pending branches immediately.  This avoids a potential race condition that would result in a UAC getting a 6xx followed by a 2xx.  In all cases except this race condition, the result will be the same - the 6xx is forwarded upstream.

o代理不再在收到6xx后立即转发。相反，他们会立即取消挂起的分支。这避免了潜在的竞争条件，这种情况会导致UAC先获得6xx，然后获得2xx。在除此竞争条件外的所有情况下，结果都是相同的——6xx向上游转发。

   o  RFC 2543 did not address the problem of request merging.  This occurs when a request forks at a proxy and later rejoins at an element.  Handling of merging is done only at a UA, and procedures are defined for rejecting all but the first request.

​o RFC 2543没有解决请求合并的问题。当请求在代理处分叉，然后在元素处重新加入时，就会发生这种情况。合并的处理仅在UA处完成，并且定义了拒绝除第一个请求以外的所有请求的过程。