一、通用设计
1.1 架构
1.1.1 通信图
下面的图展示了SIP消息在PJSIP组件间从后端到前端如何传递的。
1.1.2 类图
下面的图显示类视图
1.2 Endpoint
SIP 协议栈的核心是SIP endpoint，它由透明的pjsip_endpoint的表示，endpoint具有下面的属性和职责
l 内存储工厂，为所有的SIP组件分配内存
l 具备定时器堆实列，为所有的SIP组件调度定时器
l 传输管理起实例，传输管理器负责传输SIP消息并且控制消息的解析和打印。
l 拥有单实例PJLIB io 队列，IO队列采用proactor模式分发事件。
l 提供了线程安全的轮询功能，应用程序的线程能够查询定时器和socket事件（PJSIP自身不常见任何线程）
l 管理PJSIP模块，PJSIP模块主要以为着扩展SIP stack，而不仅仅限于消息的解析和打印。
l 从传输模块接收SIP消息，并且分发到各个模块中。
1.2.1 内存池分配和释放
为了保证线程的安全性以及在整个应用中策略强一致性，所有的SIP内存都需要在endpoint中完成分配。比如：内存池缓存，未使用的内存被保留在以后使用而不是销毁。
Endpoint提供下面的函数分配和释放内存池
pjsip_endpt_create_pool()
pjsip_endpt_release_pool()
当endpoint被pjsip_endpt_create()创建时,应用一定要指明由endpoint使用的内存池工厂。在整个生命周期内Endpoint持有内存池工厂的指针，将来备用创建和释放内存。
1.2.2 定时器管理
Endpoint 拥有一个独立定时器堆实例，所有SIP组件的定时器创建和调度都需要通过endpoint 完成。Endpoint提供下面的函数管理定时器
pjsip_endpt_schedule_timer()
pjsip_endpt_cancel_timer()
endpoint的poll函数被调用时，检查定时器是否过期。
1.2.3 轮询栈
Endpoint 提供独立的函数(pjsip_endpt_handle_events())为了检查定时器和网络事件的出现，应用可以指定准备等待多久去检查事件的出现。
Pjsip 栈从不创建线程，整个栈的运行过程都依赖于应用所创建的线程，不管是API被调用或者是轮询函数被调用。
轮询功能优化等待时间依赖于定时器堆的内容，比如：当它找到定时器将在下个5S过期，他等待socket事件的时间，将不会比5S长，在无网络事件出现时，应用程序等待超过5S是没有必要的，当然每个平台的定时器的精度是不一样的。
1.3 线程安全和线程的兼容性
1.3.1 线程安全
线程安全的讨论是比较麻烦的事情，但是，幸运的是，下面的设计原则，在整个协议中的应用都保持了一致性。
对象一定是线程安全的，但是数据结构一定不是线程安全的。
看到这个主题，很自然的想到，对象和简单数据结构的区别不是那么清晰，但是有一些例子可以提供，可能更明白写。
数据结构的例子：
PJLIB的数据结构，比如：
l 链表、数组、哈希表、字符串、内存池。
l SIP消息的元素，URLs、header fields和SIP消息
这些数据结构并不是线程安全的，数据结构的线程安全由包含他们的对象保证。如果数据结构是线程安全的，将会严重的影响协议栈的性能并且消耗操作系统的资源。
相比之下，PJSIP的对象一定是线程安全的，比如：
l PJLIB 对象，比如ioqueue
l PJSIP 对象，比如： endpoint、transactions、dialogs等。
1.3.2 复杂性
更糟糕的是，一些对象在头文件中暴露了他们的声明（pjsip_transaction 和 pjsip_dialog）。
虽然API暴露可以保证线程的安全性，应用在访问数据结构前，必须通过pj_mutex_lock获取到对象的互斥锁。
更糟糕的是，dialog暴露的不同的API锁定dialog，应用程序应该调用pjsip_dlg_inc_lock和pjsip_dlg_dec_lock() 替代pj_mutex_lock和pj_mutex_unlock。两种处理方式区别是：
Dialog的inc/dec保证了dialog将不会被销毁在函数调用时。而pj_mutex_unlock会因为dialog销毁了而导致层序crash。
考虑下面的例子：
pj_mutext_lock(dlg->mutex)
pjsip_dlg_end_session(dlg,…)
pj_mutex_unlock(dlg->mutex)
在上面的例子中，应用可能会crash，因为pjsip_dlg_end_session可能会销毁dialog在某些情况下。例如：INVITE事务没有被应答，事务会被马上销毁，导致dialog被立刻销毁。Dialog
Inc/dec可以通过增加dialog的引用计数，防止这类情况的发生。再end_session时，dialog 不会被销毁，dialog 可能会在dec_lock函数中被销毁。所以正确的调用顺序应该如下：
Pjsip_dlg_inc_lock(dlg)
Pjsip_dlg_end_session(dlg)
Pjsip_dlg_dec_lock
最最糟糕的是，锁的调用顺序一定是正确的，否则引起死锁。比如：应用想去锁dialog和dialog 的 transaction，应用必须获得dialog mutex在获取transaction mutex之前，否则当其他的线程以相反的顺序拿锁时，将会引起死锁。
1.3.3 解决办法
幸运的是，应用程序很少会直接获取对象的锁，所以上面的问题很少会发生。应用应该使用对象的API访问对象，API会对象检查，保证了lock的正确性，避免了死锁和crash的产生。
应用程序的回调被对象调用，这些回调被调用时，对象的锁已经获取到了。所以应用能够安全的获取对象的数据结构，不必要获取对象的锁。