Proxy SIP代理401响应处理

Proxy SIP代理401响应处理,proxy,sip,state-machine,digest-authentication,Proxy,Sip,State Machine,Digest Authentication,我希望得到一些关于SIP代理从下游UAS代理401响应时的预期行为的澄清 我们的SIP代理配置为以循环方式代理下游请求。如果下游UAS使用401响应INVITE,我希望SIP代理保持足够的状态,以便在发起的上游UAC发送包含身份验证凭据的第二个INVITE时选择该UAS作为目标 相反,我看到的是SIP代理将代理401响应,从上游UAC接收ACK,并立即销毁与此对话框相关的所有状态。然后,当上游UAC发送带有身份验证凭据的第二个INVITE时,SIP代理将以循环方式转发该请求。如果幸运的话,SIP

我希望得到一些关于SIP代理从下游UAS代理401响应时的预期行为的澄清

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

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


我是SIP新手,我一直在阅读RFC3261,试图理解正确的行为应该是什么,但我没有看到一个明显的答案。

我想你真正想问的是理解对话框中的进一步请求是如何工作的。为此,您需要了解“记录路由”/“路由”标题

不管响应代码是什么,对话框中的下一个请求将直接转到远程URI,除非(而且几乎总是)提供了路由集

根据RFC 3261第12节:

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

来自第16.6节请求转发

从20点34分开始

Route header字段用于强制路由请求 通过列出的代理集。使用 路线标题字段见第16.12.1节

从12.1.2 UAC行为

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

从16.12开始代理路由处理摘要

如果没有与此相反的当地政策,则处理程序a
代理对包含路由头字段的请求执行的操作可以是
总结如下步骤

  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.
看看这是如何工作的

因此,基本上,初始请求应该建立“路由集”,然后用于在下面的请求中生成“路由”头

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


两者之间也存在差异,这也可能在这里起作用。我假设您将使用lr-tho。

您是正确的,没有在exchange中的任何位置插入任何记录路由或路由头。但是,我想知道为什么需要这样做。记录路由仅由代理插入,因此,如果代理之后的下一个跃点不是另一个代理,而是远程URI(如代理只是一个负载平衡器),那么它肯定不会列在记录路由头中。代理仍然需要记住前面的选择,才能正确处理第二个邀请。我注意到第二个邀请没有第一个邀请的“to标记”,所以这可能是相关的?添加记录路由是可行的。所以,对于可以从循环中“删除”的代理,是的,它们不会在循环中添加记录路由。很难知道谁错在这里。你可以说是sip代理没有添加记录路由,你可以责怪主代理处理邀请。如果身份验证实现得“很好”,那么无论哪个代理获得邀请,它都应该能够验证它是否成功通过身份验证。还有一个问题是,如果对请求进行了签名,那么除非退出请求,否则无法修改请求。因此中间的代理必须是无状态的,或者知道如何验证请求。
  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.