RFC3261: SIP:18.1.1 客户端发送请求

18.1.1 Sending Requests
18.1.1 客户端发送请求

   The client side of the transport layer is responsible for sending the request and receiving responses.  The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations.

传输层的客户端负责发送请求和接收响应。传输层的用户将请求、IP地址、端口、传输以及可能的多播目的地TTL传递给客户端传输。

   If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed.  This prevents fragmentation of messages over UDP and provides congestion control for larger messages.  However, implementations MUST be able to handle messages up to the maximum datagram packet size.  For UDP, this size is 65,535 bytes, including IP and UDP headers.

​如果请求在路径MTU的200字节内，或者大于1300字节且路径MTU未知，则必须使用RFC 2914[43]拥塞控制传输协议（如TCP）发送请求。如果这导致传输协议与顶部Via中指示的协议发生变化，则必须更改顶部Via的值。这可以防止UDP上的消息碎片化，并为较大的消息提供拥塞控制。然而，实现必须能够处理最大数据报数据包大小的消息。对于UDP，此大小为65535字节，包括IP和UDP标头。

      The 200 byte "buffer" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the request.  This happens due to the addition of Record-Route header field values to the responses to INVITE, for example.  With the extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU.

消息大小和MTU之间的200字节“缓冲区”可以容纳SIP中的响应可能大于请求这一事实。例如，这是由于在对INVITE的响应中添加了Record-Route报头字段值。有了额外的缓冲区，响应可以比请求大大约170个字节，并且仍然不会在IPv4上被分段（假设没有IPSec，大约30个字节被IP/UDP消耗）。1300是基于1500字节以太网MTU的假设在路径MTU未知时选择的。

   If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP.  This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP.  It is anticipated that this behavior will be deprecated in a future revision of this specification.

​如果由于这些消息大小限制，某个元素通过TCP发送请求，而该请求本来会通过UDP发送，如果尝试建立连接生成不支持的ICMP协议，或导致TCP重置，则该元素应使用UDP重试该请求。这只是为了提供与不支持TCP的符合RFC 2543的实现的向后兼容性。预计此行为将在本规范的未来修订版中被弃用。

   A client that sends a request to a multicast address MUST add the "maddr" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the "ttl" parameter with a value of 1.  Usage of IPv6 multicast is not defined in this specification, and will be a subject of future standardization when the need arises.

向多播地址发送请求的客户端必须将“maddr”参数添加到其包含目标多播地址的Via报头字段值中，对于IPv4，应添加值为1的“ttl”参数。本规范中没有定义IPv6多播的使用，当需要时，将成为未来标准化的主题。

   These rules result in a purposeful limitation of multicast in SIP. Its primary function is to provide a "single-hop-discovery-like" service, delivering a request to a group of homogeneous servers, where it is only required to process the response from any one of them.  This functionality is most useful for registrations.  In fact, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first response, and view any others as retransmissions because they all contain the same Via branch identifier.
​
这些规则导致了对SIP中的多播的有目的的限制。它的主要功能是提供“类似单跳发现”的服务，将请求传递到一组同类服务器，在这些服务器中只需要处理其中任何一个服务器的响应。此功能对注册最有用。事实上，根据第17.1.3节中的事务处理规则，客户端事务将接受第一个响应，并将任何其他响应视为重传，因为它们都包含相同的Via分支标识符。

   Before a request is sent, the client transport MUST insert a value of the "sent-by" field into the Via header field.  This field contains an IP address or host name, and port.  The usage of an FQDN is RECOMMENDED.  This field is used for sending responses under certain conditions, described below.  If the port is absent, the default value depends on the transport.  It is 5060 for UDP, TCP and SCTP, 5061 for TLS.

在发送请求之前，客户端传输必须在Via报头字段中插入“sended-by”字段的值。此字段包含IP地址或主机名以及端口。建议使用FQDN。此字段用于在特定条件下发送响应，如下所述。如果没有端口，则默认值取决于传输。UDP、TCP和SCTP为5060，TLS为5061。

   For reliable transports, the response is normally sent on the connection on which the request was received.  Therefore, the client transport MUST be prepared to receive the response on the same connection used to send the request.  Under error conditions, the server may attempt to open a new connection to send the response.  To handle this case, the transport layer MUST also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the "sent-by" field.  It also MUST be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures described in Section 5 of [4].

​对于可靠的传输，响应通常在接收请求的连接上发送。因此，客户端传输必须准备好在用于发送请求的同一连接上接收响应。在出现错误的情况下，服务器可能会尝试打开新的连接来发送响应。为了处理这种情况，传输层还必须准备好在发送请求的源IP地址和“sent-by”字段中的端口号上接收传入连接。它还必须准备好接收服务器根据[4]第5节所述程序选择的任何地址和端口上的传入连接。

   For unreliable unicast transports, the client transport MUST be prepared to receive responses on the source IP address from which the request is sent (as responses are sent back to the source address) and the port number in the "sent-by" field.  Furthermore, as with reliable transports, in certain cases the response will be sent elsewhere.  The client MUST be prepared to receive responses on any address and port that would be selected by a server based on the procedures described in Section 5 of [4].

​对于不可靠的单播传输，客户端传输必须准备好接收来自发送请求的源IP地址（当响应被发送回源地址时）和“sent-by”字段中的端口号上的响应。此外，与可靠的运输一样，在某些情况下，响应将发送到其他地方。客户端必须准备好接收服务器根据[4]第5节所述程序选择的任何地址和端口上的响应。

   For multicast, the client transport MUST be prepared to receive responses on the same multicast group and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request to.)

对于多播，客户端传输必须准备好在发送请求的同一多播组和端口上接收响应（即，它需要是发送请求的多播组的成员）

   If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used.

如果请求的目的地是打开现有连接的IP地址、端口和传输，建议使用此连接发送请求，但也可以打开并使用另一个连接。

   If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport user.  If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by the transport user.

如果使用多播发送请求，则会将其发送到传输用户提供的组地址、端口和TTL。如果使用单播不可靠传输发送请求，则会将其发送到传输用户提供的IP地址和端口。