在SIP消息中，我们经常会看到ACK消息。一般在整个INVITE过程的最后，我们都能看到ACK。但是，有时候，我们看不到ACK，ACK可能在传输过程中丢失。如果我们没有最终的ACK消息，我们如何保证完全可靠的传输？另外，在其他SIP请求中我们似乎没有看到ACK，只支持INVITE。在本文的讨论中，笔者特意用点对点呼叫中的ACK做一个探讨解惑，和大家一起学习。

01

ACK在SIP INVITE中的作用

在上一篇文章中，我们已经完整的介绍了100次尝试和可靠传输的关系，我们花了很多时间讨论100次尝试的问题和细节。很多读者可能也觉得，如果要完成一个完整的可靠性传输，200 OK的传输也是需要保证的。如果200 OK传输有问题，当然以后就没有ACK传输的可能了。所以在讨论ACK之前，我们先讨论一下200 OK传输的简单过程。

当200 OK传输过程开始时，被叫方响应并启动另一个定时器来计时。如果超时后对端没有收到200 OK，说明200 OK丢失，再次发送，直到主叫方收到200 OK，然后发送ACK请求，直到被叫方最终收到ACK请求消息，从而保证可靠传输的完全完成。接下来，我们来讨论一下ACK的作用。

02

对SIP协议中ACK的质疑

很多读者可能对ACK有些疑惑。ACK似乎不会自己启动任何进程，不像其他请求，比如INVITE，可以启动一个请求。那么，ACK是请求request还是响应response？根据RFC3261中对请求和响应的定义，请求的定义中规定请求必须是Method类型，而响应必须由状态码和响应短语组成。RFC3261 7.1和7.2中有这样的语法规范:

请求:

请求行=方法服务点请求-URI服务点SIP-CRLF版本

回应:

状态行= SIP版本服务点状态代码服务点原因短语CRLF

下面的例子简单地说明了请求和响应之间的区别。因此，根据定义，ACK是一种请求方法。

但令读者困惑的是，如果是请求，请求至少需要启动进程才能执行任何动作，但ACK似乎并没有执行任何进程，ACK似乎只负责发送响应消息。实际上，ACK只负责可靠传输的最终确认。所以不管读者有什么样的困惑，ACK还是一个请求。

三

ACK本身就是一个事务。

刚才作者前面提到ACK的概念好像和request的要求有些冲突。但是ACK的语法符合请求的定义，所以是请求。希望读者能明白这个概念。然而，当我们谈到SIP事务时，许多用户对ACK的使用感到非常困惑。为什么在INVITE的例子中ACK是独立的事务？要回答这个问题，我们需要根据RFC3261来解释ACK。

根据SIP transaction-17的定义，一个事务必须以请求开始，以一个或多个最终响应结束，中间可以支持多个临时响应。

具体来说，SIP事务由单个请求和对

该请求包括零个或多个临时响应

一个或多个最终响应。

但是，在RFC3261-17中，transaction对transaction有另一种特殊的解释。可能一般读者没注意到这个解释。它是这样定义的:

在请求是邀请的交易的情况下(称为邀请交易)

如果响应是2xx，则ACK不被视为事务的一部分。

根据这个定义，ACK可以构成自己独立的事务。所以，如果满足以上条件(这里的响应是200 OK)，ACK本身就是一个事务。

如果读者能理解上面的解释，就可能彻底理解为什么ACK在一个完整的调用过程中是一个独立的事务。

04

ACK只能在INVITE中看到。

在SIP呼叫中，为什么我们只能在INVITE的请求中看到ACK，而在其他请求(比如BYE)中看不到？

BYE中没有ACK:

现在，让我们解释一下为什么。其实道理也很简单。大多数情况下，INVITE请求发出后，电话系统需要人工干预，比如等待被叫方接听，而其他请求则不需要人工干预，比如BYE和registration。

BYE请求是一种没有ACK的使用场景。如果一方挂机，不需要另一方人工干预，挂机的一方只需回复200 OK即可实现整个过程的完整性。

接下来，注册也是如此。如果UAC需要向服务器发送注册请求，服务器只需根据注册请求的信息验证其身份，无需人工干预。当服务器验证UAC的信息时，它会自动返回一个最终的响应消息。

但是，如果是邀请请求，流程就完全不一样了。因为，如果呼叫者发起呼叫，另一个电话就会响。响铃时间内，如果被叫方不在工作台，电话一直响，等待被叫方接听和接听电话需要一段时间。这时候就需要人工干预来完成一个可靠的传输过程。当然，用户可以设置一些软交换呼叫路由(在SIP头添加alter-info: Ring Answer)，终端电话(设置响铃应答)也可以实现呼叫的自动应答，这是另外一个话题。

从上面的例子可以看出，其他的非邀请都是可以通过自动处理实现的，不需要人工干预。因此，在INVITE中只有带有ACK的请求回复，而在其他请求中没有带有ACK的请求回复。

05

ACK的其他讨论

由于篇幅原因，我还没有充分讨论ACK的语法和完整细节，因为ACK请求涉及很多不同的场景，灵活性很大。具体细节请参考RFC3261。在这里，我们简单讨论一下可能经常遇到的问题。

首先，说到SIP事务，你要注意，INVITE中的ACK是一个独立的事务(就像我们刚才提到的)。

其次，ACK在某些场景下可能会被忽略，比如无状态服务器中ACK的处理机制。根据RFC3261 8.2.7，在无状态UAS中，ACK请求必须被忽略。我们必须注意这一点。

最后，ACK的处理机制取决于最终响应的类型。当UAC发起初始化请求时，UAC需要为每个最终响应发送一个响应消息(300-699)，但是处理这个ACK的机制完全取决于响应的响应类型。处理交易时遵循特定的规则。关于规则的定义，读者可以参考REFC3261的17章。

06

摘要

在本文中，作者首先介绍了INVITE的调用过程中ACK的组成和必要性，然后读者说明ACK是请求还是响应。接下来，作者讨论了非邀请请求中没有ACK的原因。最后，作者讨论了其他一些需要特别注意的方面。

通过以上论述，作者为读者提供了对ACK的一个相对全面的认识。为了便于说明，作者在例子中只使用了点对点的调用，不涉及多个代理之间的调用和多跳的处理。所以ACK过程的讨论是比较基础和简单的。如果讨论复杂的ACK处理机制，就需要涉及SIP的其他概念和内容。由于篇幅原因，我们不需要过多讨论。希望读者理解，我们会根据实际内容的安排，在以后的章节中更深入地讨论。