最初我一直在寻找一个答案，为什么对2xx响应的ACK形成一个单独的SIP事务，而对非2xx响应的ACK则没有。谷歌给了我这个：
“当UAC收到200 OK时，客户端事务将在TL处销毁。
这样做是因为TL不知道上述核心。以上 core可以是Proxy或UAC核心。
如果是代理，则转发200 OK，而对于UAC，则转发 生成ACK。现在这个ACK必须 创建一个新事务（由INVITE创建的事务已经完成 在TL处传输，因此200 OK的ACK是 在INVITE交易之外。
对于其他非2xx最终响应，TL的客户端事务不是 销毁，并由TL生成ACK。
因此，在这种情况下，ACK在交易中。“
http://sipforum.org/pipermail/discussion/2011-June/008499.html
现在我的下一个问题是为什么客户端交易在收到200 Ok后在TL处销毁。是因为ACK直接发送到UAS而不传递中间代理吗？ （因此代理永远不会知道INVITE事务是否真正完成）。
我遇到的另一个可能相关的问题是，我不明白为什么要重新传输200 OK才能完成。有没有理由不以逐跳的方式进行重传？
答案 0 :(得分：2)
关于为什么SIP使用不同的ACK机制的哲学答案是谨慎地折磨任何愚蠢的人来挖掘SIP标准的内容。
为什么UAS会处理200 OK重传？
答案详见SIP RFC Chapter 17 Transactions（在您提供的sipforum链接中也会引用）。
这种分离的原因在于其重要性 向INVA提供对INVITE的所有200（OK）响应。交付 他们都是UAC，UAS独自承担责任 重新传输它们（参见第13.3.1.4节），并且仅使用UAC 用ACK确认它们的责任（参见章节 13.2.2.4）。由于此ACK仅由UAC重新传输，因此它实际上被视为自己的事务。
换句话说，SIP设计人员担心通过UDP传送2xx响应的可靠性，因此他们决定从客户端（UAC）向服务器（UAS）发送ACK请求是实现重传的好方法。 / p>
我从未真正理解为什么SIP不能仅使用相同的机制来实现2xx和非2xx ACK。这将使实现者的工作更容易。
现在我的下一个问题是为什么客户端交易在收到200 Ok后在TL处销毁。是因为ACK直接发送到UAS而不传递中间代理吗？
如果INVITE请求遍历了SIP代理或代理，则ACK请求可能会遍历相同的代理（2xx响应可以更改同一SIP对话中后续请求中使用的代理，因此理论上ACK可以遍历不同代理）。因此，客户端（UAC）上的ACK请求处理不是为处理不同SIP路由的请求而设计的。
我遇到的另一个可能相关的问题是我不明白 为什么端到端地重传200 OK。有原因吗？ 重传不是逐跳的方式吗？
因为SIP标准要求由UAS处理INVITE响应重传的责任。无状态SIP代理没有UAS功能，它只是将收到的任何请求或响应传递给下一个SIP代理。
然而，仅仅为了混淆事情，有状态SIP代理或B2BUA可以很好地实现UAS功能，并且在这些情况下，重传将在逐跳的基础上发生，尽管在这种情况下每个INVITE事务在UAC和之间。代理或B2BUA中的UAS，而不是目标SIP客户端中的UAS。
答案 1 :(得分：0)
因此问题＆＃34;为什么ack是一个单独的交易，如果200 OK＆＃34;根本不是问题。这已在3261中解释.200 OK（就此而言任何最终响应）应该结束交易。因此，新请求将成为新事务。没有惊喜!!
真实且令人不安的问题是，如果响应不是200 OK，为什么ACK会成为邀请事务的一部分。阅读上面的链接，原因就在那里。
感谢。
答案 2 :(得分：0)
UAS为什么要处理200 OK重新传输？
在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。