RFC3261: SIP:18.2.1 服务端接收请求

18.2.1 Receiving Requests
18.2.1 服务端接收请求

   A server SHOULD be prepared to receive requests on any IP address, port and transport combination that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating with that server.  In this context, "handing out" includes placing a URI in a Contact header field in a REGISTER request or a redirect response, or in a Record-Route header field in a request or response.  A URI can also be "handed out" by placing it on a web page or business card.  It is also RECOMMENDED that a server listen for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces.  The typical exception would be private networks, or when multiple server instances are running on the same host.  For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP.  This is because a message may need to be sent using TCP, rather than UDP, if it is too large.  As a result, the converse is not true.  A server need not listen for UDP on a particular address and port just because it is listening on that same address and port for TCP.  There may, of course, be other reasons why a server needs to listen for UDP on a particular address and port.

​服务端应准备好接收任何IP地址、端口和传输组合的请求，这些请求可能是为了与该服务器通信而在SIP或SIPS URI[4]上进行DNS查找的结果。在这种情况下，“分发”包括在REGISTER请求或重定向响应的Contact报头字段中，或在请求或响应的Record-Route报头字段中放置URI。URI也可以通过放置在网页或名片上来“分发”。还建议服务端侦听所有公共接口上的默认SIP端口（5060用于TCP和UDP，5061用于TCP上的TLS）上的请求。典型的例外情况是专用网络，或者多个服务器实例在同一主机上运行。对于服务器侦听UDP的任何端口和接口，它必须侦听TCP的同一端口和接口。这是因为如果消息太大，则可能需要使用TCP而不是UDP发送消息。因此，反之亦然。服务端不需要在特定地址和端口上侦听UDP，因为它正在侦听TCP的同一地址和端口。当然，服务端需要侦听特定地址和端口上的UDP可能还有其他原因。

   When the server transport receives a request over any transport, it MUST examine the value of the "sent-by" parameter in the top Via header field value.  If the host portion of the "sent-by" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a "received" parameter to that Via header field value.  This parameter MUST contain the source address from which the packet was received.  This is to assist the server transport layer in sending the response, since it must be sent to the source IP address from which the request came.

当服务器传输通过任何传输接收到请求时，它必须检查顶部Via报头字段值中“sended-by”参数的值。如果“sended-by”参数的主机部分包含域名，或者包含与数据包源地址不同的IP地址，则服务器必须将“received”参数添加到该Via报头字段值中。此参数必须包含接收数据包的源地址。这是为了帮助服务器传输层发送响应，因为它必须发送到请求所来自的源IP地址。

   Consider a request received by the server transport which looks like, in part:

考虑服务器传输接收到的一个请求，该请求在一定程度上看起来像：

      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060

   The request is received with a source IP address of 192.0.2.4. Before passing the request up, the transport adds a "received" parameter, so that the request would look like, in part:

收到的请求的源IP地址为192.0.2.4。在传递请求之前，传输会添加一个“received”参数，这样请求在一定程度上看起来像：

      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4

   Next, the server transport attempts to match the request to a server transaction.  It does so using the matching rules described in Section 17.2.3.  If a matching server transaction is found, the request is passed to that transaction for processing.  If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request.  Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed.  This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed.

​接下来，服务端传输尝试将请求与服务端事务相匹配。它使用第17.2.3节中描述的匹配规则进行匹配。如果找到匹配的服务端事务，则将请求传递给该事务进行处理。如果没有找到匹配项，则将请求传递给核心，核心可以决定为该请求构造新的服务端事务。请注意，当UAS核心向INVITE发送2xx响应时，服务端事务将被销毁。这意味着，当ACK到达时，将不会有匹配的服务端事务，并且基于此规则，ACK被传递到UAS核心，在那里进行处理。