关于两大平台的传说很多。一些读者也可能觉得奇怪，为什么要同时介绍两个不同的平台。事实上，从一开始，这两个项目都是从这个历史脉络发展而来：SER->OpenSER->Kamailio/OpenSIPS。可以这样说，SER是可能很多通信技术人员开始学习SIP软交换的第一个公开学习的平台。从2001年，德国人Andrei 基于研究的目的写了第一行SER（SIP Express Router）代码开始，基本上奠定了德国人在开源SIP软交换领域的老大地位，而且现在的Kamailio/OpenSIPS和OpenIMSCore 都和SER以前的开发人员有着非常紧密的关系。后来，一个如此强悍的团队因为种种原因分家，最后发展成目前的kamailio和OpenSIPS，还包括一个不冷不热的OpenIMSCore。至于分家的各种小道消息，笔者也不会做过多讨论，我们也不是人家团队的人员，不清楚真正的分家的原因，很多人的转发可能都是误读。不过，从媒体公开的网络媒体的解释中，Kamailio 的创始人倒是解释了很多，关于这方面的内容读者可以自己查找。我们不会关注太多八卦的东西，也不想蹭热点。
1、在一般的SIP应用场景中，我们可以看到很多关于SIP协议的功能支持描述，洋洋洒洒几千字可能都说不清楚。其实，这些功能都可以通过一个抽象的介绍，简单概括为：
- 用户定位：决定终端的地址，使用此地址进行通信。关于定位服务器的规定，读者可以参考RFC 3262。
- 用户参数协商：决定媒体使用参数和参数使用方式
- 用户的有效性：决定用户的有效性和是否建立会话
- 呼叫创建：对呼叫方和被呼叫方创建呼叫参数，并且对双方报告呼叫状态。
- 呼叫管理：管理呼叫会话转接等功能
2、SIP协议包括几个核心的模块，根据OpenSIPS或kamailio的介绍中，主要包括注册服务器，Proxy服务器和定位服务器。例如图例所示：
Kamailio的官方文档对整个SIP服务器和相关应用也给出了一个比较详细的架构图：
为了配合我们的笔记重点，我们重点讨论以上拓扑图的红色的标注部分，可能有时会涉及CDR，RTP等一些技术讨论。
由此，结合两张图例我们可以看出，关于开源软交换的讨论中，我们更多的讨论仍然基于注册服务器，代理和定位服务器，应用服务器和重定位服务器的讨论。关于以上几种服务器的技术讨论我们在以前的讲座中有具体的介绍，读者可以查阅历史文档来进一步了解这些服务器的各自特点和具体的功能。
3、当我们讨论SIP的软交换时，在具体的SIP注册或其他的流程中，大家比较常见的名词就是transactions和dialogs，它们不能用一个定义或一句话来准确定义，而且有时场景发生变化也会变化。因此，这两个名词也是我们自己经常会产生误解或者比较模糊的地方，笔者自己也经常会犯这方面的错误。所以，我们认为有必要和大家一起分享。transactions和dialogs这两个名词会一直在OpenSIPS或Kamailio服务器的配置语法中使用，所以我们必须首先了解它们二者之间的不同，才能恰当地使用一些相关的语法来处理SIP流程。
transactions和dialogs他们各自有很多不同的参数变量，如果错误使用，可能导致我们无法对其进行成功配置。
transactions是有用户代理发起，在用户端和服务器端之间进行的多个流程所组成。从用户端发起Request一直到final response（可能包括一些中间的响应消息）。在响应的消息中， 可以是以provisional 的响应消息，例如180ring，或者final 响应消息，200 OK。
如果transaction是由INVITE发起，回复的200 OK，中间没有ACK那也是一个transaction。ACK本身有自己的transaction。以上图例中就是两个transaction发生。
所有UA transaction都具有自己的transaction, 客户端有自己的transaction，服务器端则有自己的transaction。以下图例说明了UAC到UAS中间结果2个proxy发生的transaction。注意，这里的Proxy是stateful proxy。如果是stateless proxy 则transaction仅仅发生于UA之间。
如果用户正在处理一个INVITE transaction时，ACK不包含在起始transaction中。
经过Stateless proxy时的transactions, 中间没有任何transaction发生。
Dialog则表示在一定时间内两个UA的点对点关系。简单来说，Dialog也是transactions的总和。它的主要作用是处理两个UA之间的消息，并且负责处理两个UA之间的路由请求。SIP dailog 可以分为两种类型：RTC dialog和Presence Dialog。RTC dialog是由一个INVITE transaction 发起，由BYE transaction结束。Presence dialog 则是有SUBSCRIBER transaction 带一个超时头值来设置。
每个Dialog都是由一个Dialog ID来定义。Dialog ID 则有一个CallID 头域值，本地tag和远端tag来表示。
这里要注意，Dialog ID在每个UA都是不一样的，大家要切记以下几点：
- 对于UAC来说，Dialog ID中的Call-ID通过Call-ID 头域值来设置，远端tag是设置在“To” 值域中，当然，本地local tag则设置在“From” 中，这个规则适用于请求和响应中。
- 对于UAS来说，Call-ID是保持一致，但是远端tag在“To” 值域中设置，local tag则在“To”中设置。
- 只有非失败响应才能创建dialog。简单来说，2xx 和101-199 的响应带一个tag，而且这个tag的请求是INVITE的时才能创建dialog。换句话说，只有当所有成功的INVITE 发生以后，才能创建dialog。
- 一旦dialog创建以后，任何UA都可以在此dialog中创建一个新的transaction。如果UAC在已存在的dialog中发起了一个新的INVITE transaction，我们称之为RE-INVITE。
- 在kamailio支持transaction和dialog模块来实现对transaction和dialog的管理设置，它们分别是“TM”和“dialog” 模块。在未来的笔记学习中我们会涉及相关的参数说明。注意，TM顾名思义就是Transaction management模块只能支持stateful 模式，不能支持stateless模式。
4、大家知道，SIP协议本身就是一个双方响应，然后互相发送消息的协议。双方通过不同级别的收发信息获悉对方状态。我们使用了很多关于request的内容，这些request 消息对应相应的RFC标准，读者可以查阅：
在上面和以前的讲座中，我们都一般会用到final response 或者provisional 响应消息等。在SIP协议中，定义了六个分类级别，它们都各自代表不同的含义。
- 1xx are provisional responses。
- 2xx responses are positive final responses。
- 3xx responses are used to redirect a caller。
- 4xx are negative final responses。
- 5xx means that the problem is on server's side。
- 6xx reply code means that the request cannot be fulfilled at any server。
以上六种分类可以分为：provisional responses 和final responses。101-199为provisonal responses, 200-699 则都归为final responses. final responses 则继续分为positive response（200-299） 和negative response（300-699）。
以上六类响应码SIP相关组织有很多明确的解释，读者可以查阅，RFC6228和RFC3261， RFC8197等规定。
5、总结，我们主要介绍了kamailio和OpenSIPS的背景介绍，还介绍了主要的核心模块和架构，同时重点介绍了transaction和dialog的一些容易引起歧义的内容，最后推荐读者需要了解的一些请求响应的代码，这些代码在后期学习中会经常遇到，所以建议读者花一点时间多了解这些代码。在接下来的笔记中，我们会具体介绍几个核心的模块和主要功能，包括使用的安装命令和参数。
参考资料：
https://tools.ietf.org/html/rfc6228#section-Abstract
https://tools.ietf.org/html/rfc8197#section-5.1
关注微信公众号：asterisk-cn，获得有价值的行业分享。访问5060社区-开源IPPBX论坛获得技术帮助：www.ippbx.org.cn/www.hiastar.com
