SIP 代理 401 响应处理答案

【问题标题】：SIP Proxy 401 Response HandlingSIP 代理 401 响应处理
【发布时间】：2014-02-28 16:29:44
【问题描述】：

我希望在代理来自下游 UAS 的 401 响应时，了解 SIP 代理的预期行为。

我们的 SIP 代理配置为以循环方式代理下游请求。如果下游 UAS 以 401 响应 INVITE，我希望 SIP 代理保持足够的状态，以便在发起上游 UAC 发送包含身份验证凭据的第二个 INVITE 时选择这个相同的 UAS 作为目标。

相反，我看到的是 SIP 代理将代理 401 响应，从上游 UAC 接收 ACK，并立即销毁与此对话有关的所有状态。然后，当上游 UAC 发送带有身份验证凭据的第二个 INVITE 时，SIP 代理将以循环方式转发该请求。如果幸运的话，SIP Proxy 将为第二个 INVITE 选择相同的 UAS，但大多数时候它会选择其他下游目标。

我是 SIP 新手，我一直在阅读 RFC 3261 以尝试了解正确的行为应该是什么，但我没有看到明显的答案。

【问题讨论】：

标签： proxy sip state-machine digest-authentication

【解决方案1】：

我认为您真正要问的是了解对话中的进一步请求如何工作。为此，您需要了解“Record-Route”/“Route”标头。

响应代码是什么并不重要，对话框中的下一个请求将直接转到远程 URI，除非（并且几乎总是）提供了路由集。

来自 RFC 3261 的第 12 节：

路由集是需要遍历到的服务器列表向对等方发送请求。

从第 16.6 节请求转发

  4. Record-Route

     If this proxy wishes to remain on the path of future requests
     in a dialog created by this request (assuming the request
     creates a dialog), it MUST insert a Record-Route header field
     value into the copy before any existing Record-Route header
     field values, even if a Route header field is already present.

从 20.34 路线开始

Route 头域用于为请求强制路由通过列出的代理集。的使用示例路由标头字段在第 16.12.1 节中。

从 12.1.2 UAC 行为开始

路由集必须设置为 Record-Route 中的 URI 列表
响应中的标头字段，以相反的顺序获取并保留所有 URI 参数。如果
中不存在 Record-Route 头字段响应，路由集必须设置为空集。这条路线设置，即使为空，也会覆盖任何预先存在的为未来设置的路由
此对话框中的请求。

从 16.12 代理路由处理总结

在没有当地政策相反的情况下，处理a
代理对包含 Route 标头字段的请求执行
总结为以下步骤。

  1.  The proxy will inspect the Request-URI.  If it indicates a
      resource owned by this proxy, the proxy will replace it with
      the results of running a location service.  Otherwise, the
      proxy will not change the Request-URI.

  2.  The proxy will inspect the URI in the topmost Route header
      field value.  If it indicates this proxy, the proxy removes it
      from the Route header field (this route node has been
      reached).

  3.  The proxy will forward the request to the resource indicated
      by the URI in the topmost Route header field value or in the
      Request-URI if no Route header field is present.  The proxy
      determines the address, port and transport to use when
      forwarding the request by applying the procedures in [4] to
      that URI.

查看example 了解其工作原理。

所以基本上初始请求应该构建“Route-Set”，然后用于在以下请求中生成“Route”标头。

因此，对于您的问题，听起来“路由集”没有被构建和/或在响应中被发回，或者 UAC 没有使用远程目标和路由集来构建请求-下一个请求的 URI 和 Route 标头正确。

strict and loose routing 之间也有区别，这也可能在这里发挥作用。我会假设你会使用 lr 。

【讨论】：

你是正确的，没有记录路由或路由头被插入到交换的任何地方。但是，我想知道为什么需要这样做。记录路由仅由代理插入，因此如果代理之后的下一跳不是另一个代理而是远程 URI（例如代理只是负载均衡器），那么它肯定不会列在记录路由标头中.代理仍然需要记住之前的选择才能正确处理第二个 INVITE。我注意到第二个 INVITE 没有第一个 INVITE 的“to-tag”，所以这可能是相关的？
添加记录路由是可操作的。因此，对于可以“退出”循环的代理，是的，他们不会在其中添加记录路由。很难知道这里是谁的错。您可以说这是未添加 Record-Route 的 sip 代理，您可以责怪处理邀请的主代理。如果“很好”地实现了身份验证，那么无论哪个代理获得邀请都无关紧要，它应该能够验证它是否成功通过了身份验证。
还有一个问题，如果请求是签名的，那么除非你辞职，否则你不能修改请求。所以中间的代理必须是无状态的或者知道如何验证请求。