注：以下文章如需转载，请注明所属作者，转载地址，谢谢！
第二章：SIP快速路由器（The SIP Express Router）
上一章节中我们讨论了VoIP提供商的“整体框图”（the big picture）。通常，一个VoIP提供商由几个部件构成。这些部件根据规模的大小或驻留在同一台机器上或分布于多个机器上面。其中的一个部件就是SIP代理，在我们的例子中代理服务器运行的是OpenSER软件。就像它的名字一样，描述SER的最好的东西就是SIP路由器（a SIP Router）。它能够对SIP的头域进行操作并能够以极高的速度对SIP包进行路由。第三方的模块给了SER极高的灵活性来完成一些原本没有的功能，诸如NAT穿透，IMS，负载均衡等其他功能。在这一章，我们将向你展示SIP快速路由器的能力和框架。
在本章的末尾，你将能够：
l 解释SIP快速路由器（SER）到底是什么
l 在两个开源项目SER和OpenSER中作出选择
l 描述对它们的使用方案
l 辨别出openser.cfg文件中的不同的区段
l 描述SIP消息的处理过程
l 辨别松散路由和严格路由
l 辨别SIP和SDP
我们在哪儿？（Where Are We?）
VoIP提供商的解决有很多部件。为了能够对各个部件的联系保持一个整体的把握，我们将在每一个章节中展示下面这张图片。在这一章中，我们的主要的讨论围绕SIP代理部件来进行。
SIP快速路由器是什么？（What is the SIP Express Router?）
SIP快速路由器是一套兼容IETF RFC3261 sip协议的开源的SIP代理服务器。它的目的是兼容并包尽可能多的应用。
只需要起一个单独的服务，SER就可以以它“短小精悍”的特点最快速的对请求进行前转，并能够处理成千上万的用户。它被大量的VoIP的提供商所使用，也被使用在处理能力相对较弱的嵌入式IP PBX上面。它和其他一些设备的互操作性也使得它成为实际的标准。
用哪个软件，SER还是OpenSER？（What software to use，SER or OpenSER?）
SER最开始是由德国柏林的FhG Fokus研究院所开发，发布的时候是遵从GPL许可的。它的核心开发人员是Andrei Pelinescu-Onciul，Bogdan-Andrei Iancu，Daniel Constantin Mierla，Jan Janak，
还有Jiri Kuthan。之后，其他的一些人也为此作出了贡献，他们是Juha Heinamen(RADIUS, ENUM, DOMAIN, URI), Greg Fausak (POSTGRES), Maxim Sobolev
(NATHELPER), Adrian Georgescu (MEDIAPROXY), Elena Ramona Modroiu
(XLOG, DIAMETER, AVPOPS, SPEEDDIAL), Miklos Tirpak (Permissions),
等其他人。
OpenSER是SER项目的衍生品。2004年FhG Fokus进行了SER项目的副产品
的开发创立了iptel.org。2005IPtel的商业变种被卖给了TEKELEC。核心开发团队一分为二。他们中的三位成员去了iptel.org（Andrei Pelinescu-Onciul, Jan Janak, and Jiri Kuthan），另外两名成员则离开FhG，创建了一家叫做Voice-System的公司，他们也是2005年开始的OpenSER项目的主要维护人员。
这本书始于2005后半年，基于SER项目。那个时候，我对使用SER进行NAT穿透的解决方案很感兴趣。Asterisk的可伸缩性对于（host？？）SIP提供商不是足够的好，所以我转而投向SER的研究中。它的文档真的很难懂，于是乎我开始撰写自己的文档来对SIP提供商的管理者们进行培训。
在电子书完成后，我发现SER项目已经停止维护了。大部分的代码还停留在2003年。经过一点研究我找到了OpenSER项目。它似乎更有活力，它有更加新的模块，更频繁发行的版本。我于是在非常短的时间内将所有的东西转向了OpenSER。
我不想陷入SER VS OpenSER的争论中。这样的争论是毫无意义的。现在的事实就是，这本书是为OpenSER而写的。
OpenSER为第三方应用程序提供了一个灵活的可插入模型。应用程序可以被很容易的创建并插入服务器中。这种可插入模型给予了一些新的模块的开发，譬如 RADIUS, DIAMETER, ENUM,
PRESENCE 还有SMS。更新的模块每个月都会被添加进来。你可以在http://www.openser.org/docs/modules/1.2.x上查看OpenSER 1.2.x支持的模块。
它的高效和健壮使得OpenSER能够被用来为数百万的用户提供服务。在最近的2007 3月14号的性能报告中，OpenSER 1.2.x能够处理相当于400万用户的注册请求。TM（事务模块）能够每小时处理2800万通通话。完整的报告可以在http://www.openser.org/docs/openser-performance-tests/上面找到。
OpenSER不仅仅被服务提供商所使用。它还可以构造SIP应用。目前有一些SIP防火墙（SIP firewall），会话边缘处理器（Session Border Controller），和负载均衡的代码都是从OpenSER项目中借鉴的。LINKSYS选择OpenSER作为它的一款PBX的平台，可能就是因为它的资源耗用少但性能高的特性吧。
OpenSER灵活，移植性好并且可以扩展。用ANSI C开发的它能够被轻易的移植到任何平台上。使用C语言能够很容易的创建出新的模块用于扩展。近来，编程中的一些新的层次被添加了进来。使用呼叫处理语言（Call Processing Language）简化路由脚本，使用Perl实时的对请求进行处理都成为可能。WeSIP是一种应用程序的编程接口，它允许你使用Java和Servlets创建SIP应用服务对OpenSER服务器进行扩展。可以在www.wesip.com上查看WeSIP。
使用方案（Usage Scenarios）
OpenSER主要用来作为SIP代理和注册服务器。但是，它也可以被用于其他的一些应用当中，比如代理分发器（Proxy dispatches），Jabber网关（Jabber Gateway），与媒体网关和RTP代理合作来进行NAT穿透等。支持IPv4和IPv6并且能够支持多域。OpenSER可以被应用在Linux，Solaris，还有FreeBSD等平台。
OpenSER本身的创建是为了当作SIP代理服务器使用的。然而，利用它的新的模块，如今，OpenSER能够被用在如下的一些方案中：
| Modules | Functionality | |
| DISPATCHER,PATH | Load balancing | |
| MEDIAPROXY,RTPPROXY,NATHELPER | Nat Traversal | |
| PRESENCE | Presence Server | |
| IMC XMPP | Instant Messaging |
让我们看看OpenSER的大多的使用场景吧。在所有这些场景中，OpenSER就像胶水一样，将所有的SIP部件粘在一起。
l VoIP服务提供商
l 即时消息服务提供商
l SIP负载均衡
l 嵌入式IP PBX
l NAT穿透
l SIP.EDU
OpenSER 框架（OpenSER Architecture）
核心和模块（Core and Modules）
OpenSER建造在一套核心之上，这套核心负责基本的功能实现以及对SIP消息进行处理。模块则负责OpenSER的大半的功能实现。模块和在脚本中使用的命令和参数一起将他们的功能性曝露在OpenSER当中。在一个叫做openser.cfg的文件中我们对OpenSER进行配置。这个配置文件控制着哪个模块被加载以及他们对应的参数。所有的SIP流程也都在此文件中定义的一些流程块中被控制。Openser.cfg是OpenSER的主要的配置文件。
Openser.cfg文件中的各个区段（Sections of the File openser.cfg）
Openser.cfg文件有七个区段：
l 全局定义（Global definitions）：文件的这一部分包含了OpenSER的几个工作参数，包括SIP服务的监听ip端口对和debug等级。
l 模块（Modules）：包含了外部库的列表，这些外部库是核心所没有的但却是能够展现其功能的。模块的加载使用loadmodule。
l 模块配置（Modules configuratio）：模块有一些参数是需要被合适的设置的。这些参数可以使用modparam（modulename, parametername,parametervale）进行配置。
l 主路由块（Main routing block）：主路由块是进行SIP消息处理的开始之处。它控制着所有收到的消息的处理。
l 次要路由块（Secondary routing blocks）：管理员可以使用route（）命令来定义新的路由块。这些路由块就像是OpenSER脚本中的子程序一样。
l 处理响应路由块（Reply routing blocks）：响应路由块白被用来处理响应消息，通常是200 ok。
l 处理出错路由块（Failure routing blocks）：处理出错路由块用来处理一些出错情况如线路繁忙（busy）或是超时（timeout）。
注：这个文件的细节将在4，5，6，7，8，9章节中详细进行描述。
会话，对话和事务（Sessions，Dialogs，and Transactions）
理解一些在OpenSER处理过程中使用的SIP概念是很重要的：
l SIP事务（SIP transaction）：包括一条sip消息或任何重发的和对他们的直接响应消息（如，REGISTER和200 OK）
l SIP对话（SIP dialog）：两个SIP实体之间存在一段时间的关系。如，两个UAC之间由INVITE消息到BYE消息这段时间建立的对话）
l SIP会话（SIP session）：在两个SIP实体之间的一通媒体流（音频/视频/文本）
openser.cfg消息处理
openser.cfg是为了处理收到的sip消息而执行的一段脚本。例如：如果用户A想要和用户B进行通话，它就要向B发送INVITE消息。这个消息在主路由块中被处理。这个处理过程一直要延续到它找到t_relay（）（前转）或是s1_send_reply（发送出错信息）或是最终在块的末尾使用exit（）命令丢弃该消息。billing
SIP代理——期望的行为（SIP Proxy—Expected Behavior）
按照RFC3261中描述的SIP代理的基本的处理过程是非常重要的。如果不能很好的理解，将很难去配置代理服务器。
每一个代理在将请求消息发送到下一个部件时会进行路由抉择，并对请求消息作些修改。响应消息将沿着请求消息走的路线原路路由回同样的一组代理。
代理服务器既可以运作在有状态模式下也可以以无状态的模式运行。当SIP代理服务器只是被当作一个简单的SIP包前转器（forwarder）工作时，它只是按照请求消息的要求将消息包前转到一个单独的部件上。无状态模式工作的代理会丢弃它所前转的消息的任何信息。而这个特性限制则限制了对错误的处理和对费用的记录。
如果OpenSER知道200 Ok是和一个特定的INVITE相对应，那么我们就说它此时工作在有状态模式下。这意味和你现在可以在onreply_route()块中来对响应消息进行管理。而无状态下的消息处理过程不会有上下文的处理方式。无状态处理过程通常被用在类似负载均衡的应用中；在脚本中使用forward（）命令来处理。
当你需要更加复杂的资源如计费，呼叫前转，voicemail等时，有状态处理方式是你所需要的。每个事务都将在内存中被维护，并且出错信息，响应信息和重传信息都将和这些事务有所联系。有状态事务由TM（transaction module）处理，通常使用t_relay（）命令。
一个经常会被误解的概念是：所谓处理过程的有状态指的是事务而不是对话。因此，一条INVITE请求消息的有状态处理过程的结束是到收到200 OK响应为止，而不是收到BYE。
状态操作（Stateful Operation）
这只是对有状态操作的简单描述。你会在RFC3261中找到更加完整和详尽的描述。openser.cfg和上图有些相似的地方。有些过程是手工完成的，如检查Max-forwards头域，而其他一些过程则在一条命令中即可完成。更好的说明就是，当你调用t_relay()时，所有的就像描述中的前转请求处理过程都将自动完成。
当处在有状态模式下是，代理只是一个简单的SIP事务处理器而且下面的这些处理步骤都是需要的：
l 验证请求
l 预处理路由信息
l 决定请求的目的地
l 前转请求到达目标
l 处理所有响应消息
有状态代理为每一个得到的请求创建一个新的服务器事务（server transaction）。该请求的任何重传都会被该服务器事务所处理。
举个例子：对于每一个经过我们SIP代理服务器的请求，我们都会：
第一步：请求验证
l 检查消息大小，避免缓存溢出
l 检查Max-forwards头域以检测出是否发生回环（loops）
第二步：路由信息的预处理
l 如果有record-route头，处理之
第三步：决定请求的目的地
l 目的地在定位数据库中么？（对于注册用户来说）
l 可以路由到目的地么？（网关目的地）
l 能够到达外部的域么？（外部地址）
第四步：请求前转
l 调用t_relay（）函数，OpenSER将在有状态的模式下处理所有的工作任务。
第五步：响应消息的处理过程
l 通常这个过程会被OpenSER自动完成。有时候你可以使用onreply_route[]区段对一些响应作出处理。譬如：在“忙则呼叫前转”（call forward on busy）的情形中，我们可以使用486响应消息将通话转向voicemail服务器。
严格路由和松散路由之间的区别（Differences between Strict Routing and
Loose Routing
）
在路由SIP消息的过程中，有松散和严格两种不同的方法。松散路由是SIP版本2中的新方法。当使用松散路由时，R－URI从来都不会被改变，这种方法和之前的旧方法保持向后兼容。（严格路由RFC2543）
严格路由的问题是开始对话前的初始化请求消息时指定所有的代理集合的过程。这种处理过程抛弃了包含在得到的R－URI中的信息。带有带外代理（outbound-proxy）的UA的行为是不确定的。如果其中的一个部件发生错误那么整个系统都将会出错。
解决办法就是松散路由。这种方法将目标从路由信息中分离。允许每一个目的地来路由消息包，并且有机制能够保证和严格路由向后兼容。参数；lr的使用就是对松散路由的支持象征。
当SIP服务器收到一个消息，它可以决定它自己是否处在中间位置。也就是说，如果SIP服务器不愿意待在中间位置，那么它就将信息传递给用户代理的UA让他们能够能够连接起来。然后消息就将在两个用户代理间进行处理。
而如果它想要待在中间，那么就应该使用函数record_route()插入ROUTE头。
理解SIP和RTP（Understanding SIP and RTP）
在理解接下来的子区段之前，你应该要懂得一些关于SIP和RTP的知识。首先，SIP是一个使用INVITE，BYE，和CANCEL方法来控制通话的信号协议。在INVITE请求消息中的关于会话（音频/视频/文本）消息包含在SIP协议中，使用的是叫做SDP（Session Description Protocol）的协议来包含的这些信息。包含在SDP中的信息描述了两个用户代理间的一个或是更多的媒体流的配置情况。
代理服务器从不参与到媒体流中，因此他对于媒体是什么都不用了解的。换句话说，无论UA和网关指定的媒体是什么格式，它都支持。但是有时候，B2BUA（back to back user agent）如媒体代理，可以安装在同一个服务器上来处理RTP音频（也就是NAT穿透机制）。SDP协议是供给/应答模型（Offer/Answer model）。SDP供给信息嵌入在INVITE请求消息中而应答信息在在200 OK的响应消息中。
举例：摘自Ethereal：
上图中的包是一个INVITE请求消息。该请求消息中嵌入了描述会话信息的SDP包。我们可以看到这是eyeBeam软电话产生的INVITE消息。它提供使用G.729编码格式，并使用UDP的8558端口（为了安全起见，我隐藏了IP地址）。属性rtpmap:101 telephone-event/8000描述了使用的DTMF前转方法（RFC2833）。另一个设备，在这个例子中是一个网关，在200 Ok的回复中对“供给”进行了应答。
概要（Summary）
这一章中，我们学到了什么是OpenSER以及它的主要特性。现在，你可以识别出openser.cfg配置文件和它的一些配置块，如全局定义（global definitions），加载模块（load modules），模块的参数，主路由块，路由块，响应路由块和出错处理路由块。每一个代理接收的请求都按照openser.cfg脚本中的配置来进行处理。脚本的内容的组织几乎和SIP有状态代理处理过程相一致。通常OpenSER作为松散路由器来运行（SIP版本2）。最后我们介绍了SIP和SDP的概念。
扫一扫
865
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
