kamailio内置SIP解析器讨论

针对SIP代理的需求，Kamailio支持了内置的SIP解析器，解析器具备以下处理能力：

● 快速的进程 – 与通常只处理少量dialog的客户端用户代理不同，SIP服务器可以有数千个活动事务和 dialog。Kamailio支撑了许多优化解析的技巧配置。

● 仅在需要时进行处理 – SIP服务器可以以许多形式部署，从轻量级的出站代理或负载均衡器到运行用户状态服务的全功能SIP应用服务器。解析器仅对正在运行服务所需的属性进行分解，如果没有需要该片段的模块，不会再解析每个小片段或检查其有效性。

● 缓存解析的部分 – SIP消息的一部分一旦被解析，其拆分结构将被做缓存处理，从不同组件来的第二个要求来解析缓存中的版本。

● 只理解用于路由或由SIP服务器本身提供的服务的部分 – 即使在详细解析时，代理也不会检查特定于端点的头字段的内容的有效性。

● 无克隆 – SIP消息的属性通常不会克隆在单独的结构中。Kamailio保留接收消息的缓冲区，并在缓冲区内设置钩子以定位属性。

这种处理方式被称为增量解析。如果用户考虑SIP消息的结构，它有三个主要组成部分：第一行、头和正文。第一行需要特殊的解析来区分请求或响应，但头字段具有通用的格式，包括名称、冒号和正文，后面跟随着结束行。

一般情况下，解析处理比较容易。通过解析名称，然后跳到头字段的尾部，搜索适当的头字段末尾，留下头字段中正文未解析部分。SIP消息体是用来支持终端的，用于路由的SIP代理不会干预它。但是，Kamailio提供了一个SDP解析器（用于VoIP呼叫）以及一个XML解析器（用于本文档）。

就像前面介绍的，根据下图所示，Kamailio保留了缓冲区支持接收到的SIP消息的，并在返回SIP特定属性的值时指向其中的内容。

这个解析器的架构，带有对原始SIP消息的引用，它具有一定的优势，主要体现在处理速度方面；但这样的架构也有一些缺点，这些缺点作者将在本章后面章节中讨论。

如果需要访问更深层次的组件，解析器会继续分解属性，仍然指向SIP消息缓冲区内部。下一个图显示了一个分解的From头。

由于所有这些SIP属性都指向缓冲区内部，因此无需克隆这些值，这样就避免在解析期间进行大量的malloc和free内存操作。但从另外一个方面来看，如果不干预已解析的内容的情况下，则无法直接在缓冲区中更新这些值。解决办法是通过一个更新列表维护所有的删除或添加SIP消息中的值。例如，添加或删除头字段就属于此类操作。用户可以将其操作视为补丁列表，初始内容是相同的，不断增加补丁程序。下一个图表显示了删除头字段Subject并添加新标题My-Subject的内部操作流程。

在写入网络环境之前，SIP消息的修改内容将会被自动应用。用户可以通过textopsx模块导出的msg_apply_changes()函数在配置文件中按照需要来使用它们。

直到在更改应用之前，实际上部分新值不会反映在SIP属性中。例如，我们看看使用于前一个SIP消息的配置文件脚本片段：


remove_hf(“Subject”);  # removing header Subject
if(is_present_hf(“Subject”))
 { # test if the header Subject is present in SIP message # execution will ALWAYS go here
}

删除头中的Subject并立即检查其状态的话，可能会令人费解，因为这里检查将始终为真。由于Subject未有效地从SIP消息的缓冲区中删除，因此检查流程仍然会在那里找到它。其正确的处理方式：


remove_hf(“Subject”);  # removing header Subject msg_apply_changes();
if(is_present_hf(“Subject”)) 
{ # test if the header Subject is present in SIP message # execution will NEVER go here
}

通常，我们不建议用户大量使用msg_apply_changes()，因为它会重置SIP解析器状态并且影响性能执行。