RFC3261: SIP:16.12.1.2 遍历严格路由代理

16.12.1.2 Traversing a Strict-Routing Proxy
16.12.1.2 遍历严格路由代理

   In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values.  The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress.

​在这种情况下，将在四个代理之间建立一个对话，每个代理都会添加Record-Route报头字段值。第三个代理实现了RFC 2543中规定的严格路由过程，许多工作正在进行中。

      U1->P1->P2->P3->P4->U2

   The INVITE arriving at U2 contains:

到达U2的INVITE包含：

      INVITE sip:callee@u2.domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p4.domain.com;lr>
      Record-Route: <sip:p3.middle.com>
      Record-Route: <sip:p2.example.com;lr>
      Record-Route: <sip:p1.example.com;lr>

   Which U2 responds to with a 200 OK.  Later, U2 sends the following BYE request to P4 based on the first Route header field value.

然后，U2根据第一个Route报头字段值向P4发送下面的BYE请求。

      BYE sip:caller@u1.example.com SIP/2.0
      Route: <sip:p4.domain.com;lr>
      Route: <sip:p3.middle.com>
      Route: <sip:p2.example.com;lr>
      Route: <sip:p1.example.com;lr>

   P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone.  It notices that it is the element in the first Route header field value so it removes it.  It then prepares to send the request based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not contain the lr parameter, so before sending, it reformats the request to be:

P4不负责请求URI中指示的资源，因此它将不负责它。它注意到它是第一个Route报头字段值中的元素，因此将其删除。然后，它准备根据sip:p3.midle.com的第一个Route报头字段值发送请求，但它注意到此URI不包含lr参数，因此在发送之前，它将请求重新格式化为：

      BYE sip:p3.middle.com SIP/2.0
      Route: <sip:p2.example.com;lr>
      Route: <sip:p1.example.com;lr>
      Route: <sip:caller@u1.example.com>

   P3 is a strict router, so it forwards the following to P2:

P3是一个严格的路由器，因此它将以下内容转发给P2：

      BYE sip:p2.example.com;lr SIP/2.0
      Route: <sip:p1.example.com;lr>
      Route: <sip:caller@u1.example.com>

   P2 sees the request-URI is a value it placed into a Record-Route header field, so before further processing, it rewrites the request to be:

P2看到请求URI是它放置在记录路由报头字段中的值，因此在进一步处理之前，它将请求重写为：

      BYE sip:caller@u1.example.com SIP/2.0
      Route: <sip:p1.example.com;lr>

   P2 is not responsible for u1.example.com, so it sends the request to P1 based on the resolution of the Route header field value.

P2不负责u1.example.com，因此它根据Route报头字段值的解析向P1发送请求。

   P1 notices itself in the topmost Route header field value, so it removes it, resulting in:

P1在最上面的Route报头字段值中注意到自己，因此它将其删除，从而导致：

      BYE sip:caller@u1.example.com SIP/2.0

   Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI.

由于P1不负责u1.example.com，并且没有Route报头字段，因此P1将根据请求URI将请求转发到u1.example.com。