Question

这个问题与SIP（会话发起协议）中的ACK请求有关。引用RFC-3261 - 18.1.1发送请求

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.

对于除ACK之外的INVITE和其他非邀请请求，这看起来没问题。以下是我认为上述陈述可能不适用于ACK的要点。

ACK只是一个请求，而不是事务。因此SIP事务状态机不能适用于ACK请求。由于State Machine是唯一谈论重传的地方，因此18.1.1不适用于ACK请求。引用3261 - “17.1客户交易” - 支持上述论点。

There are two types of client transaction state machines, depending
on the method of the request passed by the TU. One handles client
transactions for INVITE requests. This type of machine is referred
to as an INVITE client transaction. Another type handles client
transactions for all requests except INVITE and ACK. This is
referred to as a non-INVITE client transaction. There is no client
transaction for ACK. If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.

只有当下一个B方重新发送最终回复时才能重新发送ACK。

问： - 我的假设是否正确，在收到传输错误（例如连接错误，ICMP错误）时无法重新传输SIP ACK请求？

引用3261 - “17.1客户交易” -

If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.

此致 Sudhansu

Answer 1

1）让我们回到基本的东西

＆＃34;如果元素由于这些消息大小而通过TCP发送请求约束，并且该请求将以其他方式发送 UDP，如果尝试建立连接生成一个 ICMP协议不支持，或导致TCP重置，该元素应该使用UDP重试请求。＆＃34;

我的评论： - ＆＃34;应该重试请求＆＃34; - ＆GT;它说SHOULD重试不必重试请求。因此，发送ACK请求根本不是强制性的。

2）

问： - 我的假设是否正确，在收到传输错误（例如连接错误，ICMP错误）时无法重新传输SIP ACK请求？

引用3261 - ＆＃34; 17.1客户交易＆＃34; -

如果TU希望发送ACK，它会直接将一个ACK传递给传输层进行传输。

评论： - 这清楚地说明了TU（交易用户）是否希望{不必}将ACK请求传递给传输层以进行传输。

因此，根据声明，它的应用程序希望一旦将其传递给ACK到传输层，就不会做任何事情。或者如果在另一方面，如果应用程序想要有任何TCP错误（ICMP），那么它可以通过UDP重新发送相同的ACK请求。

请参阅RFC，绝不会从中排除ACK，这是应用程序的责任＆amp;它是如何实现的。另外，请也可以在Sip-implementors邮件列表中提问。你会变得更像志同道合的人。

Answer 2

首先澄清一些。来自RFC3261 Section 6：

SIP事务：SIP事务发生在客户端和客户端之间服务器并包含发送的第一个请求的所有消息从客户端到服务器直到最终（非1xx）响应从服务器发送到客户端。如果请求是INVITE 并且最终的回复是非2xx，交易也是包括对响应的ACK。对2xx响应的ACK INVITE请求是一个单独的事务

因此，对非2xx的ACK是与INVITE，任何1xx响应和最终响应相同的事务的一部分。特别是它具有相同的CSeq和相同的分支标签。对非2xx响应的ACK是逐跳的。

对2xx的ACK是一个新事务（尽管这是一个特殊的ACK事务，并且没有响应）。它具有相同的CSeq，但具有不同的分支标记。对2xx响应的确认从客户端一直到服务器。

关于你的具体观点，第17节是关于交易层的。这里，ACK仅响应于重新发送的最终响应而被重新发送。当事务层决定它需要发送ACK时，它会将其发送到传输层，并且它是传输层的作业。

第18节是关于传输层的。 ICMP错误或TCP重置是传输层错误，它们不在SIP事务模型中。如果传输层需要将消息从UDP提升为TCP，或者从TCP回退到UDP，那么它与事务层模型是分开的。实际上，如果无法建立TCP套接字，则尚未发送ACK。在这种情况下，传输层不会重新传输它，它会尝试通过不同的协议首次传输它。

在实践中，这种情况很少见。由于ACK的大小是UDP的问题，它必须大于INVITE和最终响应 - 这些已经通过UDP成功。在通常情况下，INVITE和最终响应包含SDP主体;在每个成功案例中，2xx包含一个正文。 ACK最大的唯一情况是INVITE中没有SDP，并且ACK会添加到标题或正文中。

如果遇到这种情况 - 不支持TCP并且UDP太大，那么无论如何你都可能会失败。

SIP ACK请求重新传输传输错误

2 个答案: