set transaction 必须是事务处理的第一个语句_SIP呼叫中的Call，Dialog和Transaction

现在使用最广泛的VoIP协议应该是SIP协议。在我们的文章中，我们会经常使用一些SIP协议中一些专有的技术名称。他们对基本概念可能读者非常了解，但是如果结合具体的示例，理解一个呼叫中究竟这些名称之间存在什么关系和他们之间的产生的数量是，可能就会产生迷惑，例如呼叫中发生了几个dialog，发送了几个transactions。以下图例简单说明了一个最简单的示例。

当然，在实际生产环境中，双方呼叫不仅仅是一个点对点的呼叫。大部分呼叫需要经过一个代理服务器来处理。今天，我们结合几个具体的示例重新和大家分享一下比较完整的呼叫流程，看看在呼叫过程中到底发生了多少个dialog和transactions。

为了回答这些问题，我们会首先介绍一下rfc3261的定义细节，然后给出几个示例结合rfc3261的规范来解释Dialog和Transactions发送的数量。因为以前的文章中大量介绍了这些名称的基本概念，我们不再过多介绍其它完整的概念和相关背景知识。读者可查阅我们的历史文档或者参考rfc3261来进一步了解学习。

01

Call/Session的定义

通常大家所说的SIP call或者call其实在规范中没有非常明确的官方定义，这是一个非常口语化的说法。一般来说，call可以表示为session，一个SIP呼叫至少具有以下几个方面的特点：

• 首先是一个session 会话
• 其次，它必须包括所有的初始，管理和结束会话的所有消息
• 通过Call-ID 头来确认其身份

为了能够让读者完整准确理解我们接下来的讨论，我们使用稍微复杂一点的forking呼叫的示例来说明call，dialog和transactions的关系以及呼叫过程中各自的数量。

如果我们换一个示例，通过完整的消息流程看到话，读者可能更加清晰一点。

02

Dialog的定义

关于Dialog的定义，RFC3261是这样定义Dialog的：

A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them.

从定义来看，Dialog本质上说是一种对对点关系的确认。呼叫方UA发起呼叫后，可能导致一个或多个Dialog。Dialog的身份确认通过To tag和From tag组合确认，简单来说，一个Dialog是有本地呼叫方和远端被呼叫方构成。

03

Transaction的定义

关于Transaction的定义我们在前面的文章中有过全面地介绍，另外读者也可以查阅RFC3216来学习。这里，我们重点说明成功呼叫和失败呼叫的Transactions导致的不同处理流程。不同呼叫结果导致不同的事务处理结果，因此，两种Transaction具有以下特点：

• 成功呼叫的transaction：以一个请求开始，以零个或多个最终协议结束，其中可能包含多个临时响应，ACK除外。
• 失败呼叫的Transaction：包含失败响应消息，ACK包括在了INVITE事务中。
• Transaction通过Via头中的branch参数和CSeq method来确认。
• 仅留存在一个hop中，经过代理处理的请求重新开始一个新的Transaction。

04

关于Dialog数量讨论

根据前面讨论中关于Dialog的定义，结合以下场景，我们知道，以下场景中产生了2个Dialog。第一个Dialog是A/B之间的Dialog，第二个Dialog是A/C之间的。这两个Dialog通过To tag和From tag 分别绑定了两个终端。因此，以下示例生成了2个Dialog。

为了方便理解，很多环境中，我们也把Dialog称之为call-leg。所以，请读者不要对其概念产生误解。

05

关于Transactions 事务的数量讨论

显然，以上讨论中call和Dialog的数量确认是相对比较简单的。比较复杂的是确认事务的数量。首先说明一下，事务生成的数量取决于多方面的条件和呼叫场景(例如INVITE和非-INVITE事务，客户端和服务器端事务，失败呼叫和成功呼叫的事务，点对点呼叫还是经过proxy代理的呼叫)，在示例中很难完全说明所有的应用场景。我们现在仅针对相对容易实现的环境做示例说明。让我们重新回顾一下关于事务的定义：

a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses.

因为我们大部分的业务和INVITE相关，因此，我们重点讨论关于和INVITE相关的事务处理。根据RFC3261的规范说明：

In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction.

所以，根据以上说明，读者一定要注意响应是 2XX响应还是非2XX 协议来计算事务生成的数量。另外，大家一定要注意，读者需要自己问自己一个问题，为什么ACK需要分开处理独立为一个新的事务？ 在RFC3261的官方中说明了为什么需要独立的ACK的原因，这是因为ACK涉及到了UAC和UAS直接重传机制的处理。关于重传机制的处理，读者可以查阅RFC3261的13.3.1.4。

下面，我们根据一个非常普遍的分叉呼叫的流程，来分别说明成功呼叫和失败呼叫各自所生成的transaction，并且说明了为什么在这个示例中产生了五个transactions。以下示例并非按照顺序生成，读者不要误解。

以上分叉呼叫发生了五个事务处理(Transactions)：

1. 第一个Transaction发生在呼叫方A 对服务器的请求，是第一个Transaction。
2. 第二个Transaction发送于服务器对SIP B的INVITE流程中，因为电话B没有接听，返回了一个487(非2XX)响应，因此紧接着SIP服务器返回了一个ACK。因为是一个失败的呼叫，所以，这个ACK是包含在INVITE中的，因此最终，这是第二个Transaction。
3. 第三个Transaction发生在电话C和服务器端之间。所以，电话C端和服务器端产生了第三个Transaction。另外，因为这是一个成功的呼叫，所以，其响应的ACK是一个独立的Transaction，因此A和C端之间产生了第四个Transaction。
4. 第五个Transaction产生于SIP服务器和电话B之间的失败呼叫中，Cancel是一个独立的Transaction而存在(非INVITE)，这是第五个Transaction。

6

三者之间的关系

我们在前面的章节中讨论了call，dialog和transactions的三个SIP呼叫中非常重要的概念，并且对其不同的流程所产生的处理数量做了比较清晰的介绍。

从其概念和实际场景中，我们可以看出其三者之间的关系。简单来说，它们之间的关系是：

1. 一个Call可能存在至少一个或者多个Dialogs
2. 一个Dialog由一系列多个Transactions事务构成
3. Transaction事务各自都是互相独立的

07

总结

在本章节中，笔者重点介绍了SIP 环境中call，Dialog和Transaction的基本概念和其三者之间的关系，并且针对典型的SIP INVITE 呼叫环境下它们各自所生成的数量。笔者特别针对比较复杂的事务处理的数量做了非常详细地说明和介绍，并且根据RFC3261对其的定义，花费一定时间对其非2XX响应和2XX响应所产生的事务和独立生成ACK的原因。

笔者希望通过本章节对事务处理的介绍，帮助读者能够完整了解事务生成的数量和其原因。

最后，笔者这里仅介绍了INVITE请求时事务的处理，更多关于其他非INVITE或者其他的事务处理的环境读者需要根据具体的环境来进行进一步学习。

参考资料：

http://www.siptutorial.net/SIP/relation.html

http://www.kamailio.org/docs/tutorials/sip-introduction/#sip_transactions

https://subscription.packtpub.com/book/networking_and_servers/9781849510745/1/ch01lvl1sec13/sip-transactions-and-dialogs

https://arstechnica.com/tech-policy/2010/03/voip-in-depth-an-introduction-to-the-sip-protocol-part-2/

https://www.tech-invite.com/fo-sip/tinv-fo-sip-dialog-05.html

Jae Cheon Han，A study on ACK message processing mechanism in SIP transaction layer