RFC3261: SIP:16.12.1.1 基本SIP梯形

16.12.1.1 Basic SIP Trapezoid
16.12.1.1 基本SIP梯形

   This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing.  Here is the flow.

这个场景是基本的SIP梯形，U1->P1->P2->U2，两个代理都记录路由。这是流程。

   U1 sends:

      INVITE sip:callee@domain.com SIP/2.0
      Contact: sip:caller@u1.example.com

   to P1.  P1 is an outbound proxy.  P1 is not responsible for domain.com, so it looks it up in DNS and sends it there.  It also adds a Record-Route header field value:

到P1。P1是一个出站代理。P1不负责domain.com，所以它在DNS中查找并发送到那里。它还添加了一个记录路线报头字段值：

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

   P2 gets this.  It is responsible for domain.com so it runs a location service and rewrites the Request-URI.  It also adds a Record-Route header field value.  There is no Route header field, so it resolves the new Request-URI to determine where to send the request:

P2明白了。它负责domain.com，因此它运行位置服务并重写请求URI。它还添加了一个记录路由报头字段值。没有路由报头字段，因此它解析新的请求URI以确定将请求发送到哪里：

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

   The callee at u2.domain.com gets this and responds with a 200 OK:

u2.domain.com上的被调用者收到此消息，并以200 OK进行响应：

      SIP/2.0 200 OK
      Contact: sip:callee@u2.domain.com
      Record-Route: <sip:p2.domain.com;lr>
      Record-Route: <sip:p1.example.com;lr>

   The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to:

u2处的被调用者还将其对话状态的远程目标URI设置为sip:caller@u1.example.com并且其路由集为：

      (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

   This is forwarded by P2 to P1 to U1 as normal.  Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to:

这被P2正常地转发到P1到U1。现在，U1将其对话状态的远程目标URI设置为sip：callee@u2.domain.com并且其路由集为：

      (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

   Since all the route set elements contain the lr parameter, U1 constructs the following BYE request:

由于所有路由集元素都包含lr参数，U1构造以下BYE请求：

      BYE sip:callee@u2.domain.com SIP/2.0
      Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

   As any other element (including proxies) would do, it resolves the URI in the topmost Route header field value using DNS to determine where to send the request.  This goes to P1.  P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it.  It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2:

与任何其他元素（包括代理）一样，它使用DNS解析最上面的Route报头字段值中的URI，以确定将请求发送到哪里。这将转到P1。P1注意到它不对请求URI中指示的资源负责，因此它不会更改它。它确实看到它是Route报头字段中的第一个值，因此它删除了该值，并将请求转发给P2：

      BYE sip:callee@u2.domain.com SIP/2.0
      Route: <sip:p2.domain.com;lr>

   P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it.  It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI:

P2还注意到它不负责请求URI所指示的资源（它负责domain.com，而不是u2.domain.com），所以它没有更改它。它确实在第一个路由报头字段值中看到了自己，所以它删除了它，并根据对请求URI的DNS查找将以下内容转发到u2.domain.com：

      BYE sip:callee@u2.domain.com SIP/2.0