为什么在SIP协议中200 OK重传由UAS处理？

起初，我在寻找一个答案，为什么对2xx响应的ACK会形成一个单独的SIP事务，而对非2xx响应的ACK不会。谷歌给了我这个：

“当UAC收到200 OK时，客户事务在TL处被销毁

这样做是因为TL不知道上面的核心 核心可以是代理或UAC核心

如果是代理，则转发200 OK，而如果是UAC，则转发 已生成确认。现在必须 创建一个新事务（INVITE创建的事务已被删除） 已销毁）在TL传输，因此200 OK的ACK为 在INVITE事务之外

对于其他非2xx最终响应，TL处的客户端事务不是 销毁，由TL生成ACK

因此，在这种情况下，ACK在事务中。”

现在，我的下一个问题是，为什么在TL收到200 Ok后，客户交易被销毁。是否因为ACK直接发送到UAS而不通过中间代理？（因此代理永远不会知道INVITE事务是否实际完成）

---

我遇到的另一个可能相关的问题是，我不明白为什么200 OK的重传是一个接一个地完成的。是否有理由不以逐跳方式进行重传？

关于SIP为何使用不同的ACK机制，哲学上的答案是谨慎地折磨那些愚蠢到钻入SIP标准内部的人

---

为什么200 OK重传由UAS处理

答案详见（您提供的sipforum链接中也有提及）

这种分离的原因植根于 向UAC发送邀请的所有200（确定）响应。交付 这些都归UAC所有，只有UAS负责 重新传输它们（见第13.3.1.4节），UAC单独承担 用ACK确认的责任（参见第节 13.2.2.4). 由于此ACK仅由UAC重新传输，因此它实际上被视为自己的事务

换句话说，SIP设计人员担心通过UDP发送2xx响应的可靠性，因此他们决定从客户端（UAC）向服务器（UAS）发送ACK请求是实现重传的好方法

我一直不明白为什么SIP不能对2xx和非2xx ACK使用相同的机制。这将使实施者的工作更容易

现在，我的下一个问题是，为什么在TL收到200 Ok后，客户交易被销毁。是否因为ACK直接发送到UAS而不通过中间代理

如果INVITE请求穿过一个或多个SIP代理，则ACK请求很可能会穿过相同的代理（2xx响应可以更改同一SIP对话框中后续请求中使用的代理，因此理论上ACK可以穿过不同的代理）。因此，不，客户端（UAC）的ACK请求处理不是为处理通过不同SIP路由的请求而设计的

另一个可能与我有关的问题是我不明白 为什么200 OK的重传是一个接一个地完成的。有什么原因吗 重传不是以逐跳方式进行的吗

因为SIP标准要求邀请响应重传的责任由UAS处理。无状态SIP代理没有UAS功能，它只是将接收到的任何请求或响应传递给下一个SIP代理

---

但是为了把事情搞混,，有状态SIP代理或B2BUA可以很好地实现UAS功能，在这些情况下，重传将逐跳进行，尽管在这种情况下，每个INVITE事务都在代理或B2BUA中的UAC和UAS之间，而不是在目标SIP客户端中的UAS之间。

尝试在下面的链接中对此进行解释

因此，“在200 OK的情况下，为什么ack是一个单独的事务”根本不是一个问题。这已在3261中解释。200 OK（就此而言，任何最终响应）都应该结束事务。所以新的请求将是一个新的事务。没有意外

真正令人不安的问题是，如果响应不是200 OK，为什么ACK是invite事务的一部分。阅读上面的链接，原因就写在那里

---

谢谢。

为什么200 OK重传由UAS处理

RFC 3261第128页中的答案对我来说很清楚：

“此响应的处理取决于TU是否是代理 核心或UAC核心。UAC核心将处理为的ACK生成 此响应，而代理核心将始终转发200（正常） 上游。代理和UAC之间对200（OK）的不同处理 是不是因为没有在现场进行处理 事务层。”

我也思考了一段时间这个问题，当我想到通信路径中的代理时，我就明白了。我们知道，非2xx响应发生在事务层。代理上的事务层将响应非2xx响应的ACK。当再次接收非2xx时，事务层也将重新发送ACK

---

让我们假设，如果200 OK发生在事务层中。代理事务层将响应ACK。会话将在UAS上创建。如果200 OK最终能到达UAC，这是没有问题的。但是，这不是我们想要的结果，因为200 OK可能由于其他原因无法到达UAC。

感谢您的澄清！因此，总而言之，出于可靠性考虑，决定让UAS和UAC分别处理200 OK和ACK的重传。由于非2xx响应不会被重新传输，它们的相关ACK响应由事务层处理，因此驻留在同一事务中..？您几乎是正确的。非2xx响应仍将重新传输。SIP RFC的前提是2xx响应更符合cri