使用OpenSER构建电话通信系统

编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第205页 共205页使用OpenSER构建电话通信系统Building Telephony Systems with OpenSER(翻译人：老黑 转载地址： )第一章：SIP介绍（Introduction to SIP）会话初始化协议是互联网工程任务组（IETF）制定的协议标准，在多个RFC（Request for Comments）文档中被进行了描述说明。RFC3261是最近的一个RFC，一般称它为SIP版本2。SIP是一个应用层的协议，用来建立，修改，终止会话（sessions）或是多媒体通话（multimedia calls）。这些会话可以会议（conferences），e-learning，网络电话和一些相似的应用。它是同HTTP协议相类似的文本协议并且被设计用来发起，保持，关闭用户之间的交互会话。目前SIP已经是VoIP领域被广泛使用的协议之一了，市场上几乎每一台IP电话都会支持它。本章结束的时候你将能够：l 描述SIP是什么l 描述SIP是干什么的l 描述SIP的框架l 解释SIP主要部件的意义l 理解并比较主要SIP消息l 描述INVITE和REGISTER请求消息头部的处理过程在建立和关闭多媒体通话的过程中，SIP协议支持五种要素。l 用户定位（User location）l 用户参数协商（User parameters negotiation）l 用户可用性（User availability）l 通话建立（Call establishment）l 通话管理（Call management）SIP协议被设计成多媒体框架的一部分，而这种多媒体框架包括RTSP，RTP，RTSP还有SDP等其他协议。然而，SIP却并不依靠其他这些协议工作。SIP基础（SIP Basics）SIP在工作的方式上与HTTP协议相类似。SIP的地址像是e-mail的地址。SIP代理中使用的一个比较有趣的特性就是“别名（alias）”，也就是说你可以有多个SIP地址，譬如： johndoesipA.com +554845678901sipA.com 45678901sipA.com在SIP的体系结构中，有多个用户代理和提供不同服务的服务器。SIP使用点对点（peer-to-peer）的分布模型来和服务器进行消息的交互。服务器只进行消息（signaling）的处理，而用户代理的客户端和服务端既可以处理消息也可以处理媒体。下面的图描述了这样的一个体系：在SIP模型中，用户代理，通常是一台SIP话机与它的SIP代理进行交互，从上图可以看到，外呼代理（outgoing proxy）将使用INVITE消息向外发出通话请求。外呼代理将观察这通通话是否是被定向到外部的域名。然后它将向DNS服务器发出请求将目标域名解析为对应的IP地址。然后再将通话请求发送给DomainB对应的SIP代理。呼入代理（incoming proxy）将在地址列表（location table）中查询agentB的IP地址。如果在地址列表这个地址与之前在注册过程中的IP地址对应，那么呼入代理就可以定位这个地址了。现在就可以使用这个地址将通话请求发送到agentB了。agentB收到这个SIP消息后（INVITE），就拥有了可以与agentA建立RTP会话（通常是音频方面的会话）所需要的信息。使用BYE消息可以终止这个会话。SIP代理在VoIP提供者里的作用/上下文（SIP Proxy in the Context of a VoIP Provider）通常VoIP服务的提供者们并不会实现像上幅图那样的纯粹的SIP四边形结构，他们不会允许你向一个外部的域名发送通话请求，因为如果这样，那么将影响他们的收入（revenue stream）。取而代之的是一个接近三角形的SIP网络结构。（如下图所示）SIP工作原理（SIP Operation Theory）在上图中，你可以看到SIP体系结构中的主要的构成部件。所有的SIP消息都会经过SIP代理服务器。另一方面，由RTP协议承载的媒体流则是从一端直接流向另一端。我们将在下面的列表中简要的对其中的一些构成部件进行解释。l 用户代理客户端（UAC user agent client）发起SIP消息的客户端或终端l 用户代理服务端（UAS user agent server）对接收到的从用户代理客户端发起的SIP消息进行相应的服务端。l 用户代理（UA user agent）SIP终端（IP电话，电话适配器（ATA），软电话（softphone）l 代理服务器（Proxy Server）从用户代理接收请求，并且如果指定的被请求的终端不在其域中时，会将请求发送给另外的SIP代理。l 重定向服务器（Redirect Server）接收请求，但是不直接发送给被叫用户，而是向主叫方发送目的地址的信息。l 定位服务器（Location Server）向代理服务器和重定向服务器提供被叫者的联系地址。通常，物理上，代理服务器，重定向服务器和定位服务器存在于同一台电脑和软件中。SIP注册过程（SIP Registration Process）SIP协议中使用了一个构件叫做注册服务器。它不仅能够接收REGISTER消息请求，还能够将收到的消息包中的信息保存到管理对应域名的定位服务器上面。SIP协议具有发现能力；换句话说，就是如果一个用户要与另外一个用户开始会话，那么SIP协议必须要发现这个用户能够到达的主机存在。由于定位服务器可以收到请求消息并找到向什么地方发送，所以这个发现过程由定位服务器来完成。而这则是基于管理每个域的定位服务器维护着一个定位数据库的事实来实现的。注册服务器不仅可以接收客户端的IP地址，还 能够接收其他类型的消息。比如，能够收到服务器上面的CPL（Call Processing Language）脚本。在一台话机能够接收一通通话之前，它需要在定位数据库中有注册信息。在这个数据库中我们要拥有所有电话的各自的相关的IP地址。在我们的例子中，你将看到SIP用户8590.br注册到200.180.1.1上面的过程。RFC3665定义实现了一个最小的功能集合，这是使得SIP进行IP网络交互时的最好实践。下面的图就是根据RFC3665中的描述所画出的注册事务处理流程。按照rfc3665中所说，与注册一个用户代理的过程相关的有五个基本的流程，如下所述：1. 一个新的成功的注册（A successful new registration）用户代理在发送Register请求后，将收到认证过程的挑战。我们将在阐述验证过程的章节中看到这个过程的细节。 2. 联系列表的更新（An update of the contact list）由于不再是新的注册，消息中已经包含了摘要（digest），那么不会返回401消息。为了改变联系列表，用户代理仅仅需要发送一条在CONTACT头中带有新的联系信息的注册信息即可。 3. 请求获得当前的联系列表在这种情况下，用户代理将把发送消息中的CONTACT头置空，表明用户希望向服务器询问当前的联系列表。在回复的200OK消息中，SIP服务器将把当前的联系列表放在其CONTACT的头中。 4. 取消注册（Cancellation of a registration）用户代理在发送的消息中将EXPIRES头置成0，并且将CONTACT头设置为“”表示将此过程应用到所有存在的联系信息。 5. 不成功的注册（Unsuccessful Registration）用户代理客户端（UAC）发送一条Register请求消息，收到一条“401 Unauthorized”消息，事实上，这个过程同成功注册过程相同。但是接下来，它进行哈希运算尝试进行认证。而服务器检测到的是一个无效的密码，继续发送“401 Unauthorized”消息。这个过程一直重复直到重复次数超过在UAC设置的最大值。 作为SIP代理运转的服务器（Server Operating as a SIP Proxy）在SIP代理模式下，所有的IP消息都要经过SIP代理。这种行为在向诸如计费（billing）的过程中帮助很大，而且迄今为止，这也是一种最普遍的选择。但是它的缺点就是在会话建立过程中的所有的SIP交互中，服务器造成的额外开销也是客观的。要记住的是，即使服务器作为SIP代理在工作时，RTP包也总是直接从一端传送到另一端，而不会经过服务器。作为SIP重定向运转的服务器（Server Operating as a SIP Redirect）SIP代理可以运行在SIP重定向模式。在这种模式下，SIP服务器的处理量是相当巨大的，因为它不需要保持事务处理的状态。在对INVITE消息进行初始化后，仅仅向UAC回复一条“302 Moved Temporarily”消息就可以离开SIP对话（dialog）了。在这种模式下的SIP代理，即使只是利用非常少的资源也可以每小时传送上百万的通话。当你需要的规模很大并且不需要对通话计费的情况下，这种模式通常会被使用。基本消息（Basic Messages）在SIP环境中会被发送的基本的消息有：大多数时间内，你会使用到REGISTER，INVITE，BYE还有CANCEL。而另外一些消息会被用在其他的特性当中。举例来说，INFO被用在DTMF relay和通话中消息信息（mid-call signaling information）。PUBLISH，NOTIFY和SUBSCRIBE则用来支持列席系统（presence systems）。REFER用来进行通话转接（call transfer）而MESSAGE则应用于一些聊天应用程序中。更新的消息也会随着协议标准化进程而随之出现。像HTTP协议一样，这些消息的响应也会以文本形式出现。其中一些最终的响应消息被列在下图当中：SIP对话流程（SIP Dialog Flow）这一节将通过一个简单的例子来介绍一些基本的SIP操作。先让我们来诊视下图展示的两个用户代理之间的消息顺序。你可以看到伴随这RFC3665描述的会话建立过程还有几个其它的流程。我们在这些消息上标上了序号。在这个例子中用户A使用IP电话向网络上的另外一台IP电话发出通话请求。为了完成通话，使用了两个SIP代理。用户A使用称为SIP URI的SIP标识向用户发出通话。URI就像是一个电子邮件地址，比如sip:userA。一种可靠安全的SIP URI也可以被使用，譬如sips:userA。使用SIPS建立的通话将会在主叫和被叫之间使用安全可靠的传输机制（TLSTransport Layer Security）事务（transaction）的建立始于用户A向用户B发送INVITE请求消息。INVITE请求中包含一些特定头域。这些头域被称之为属性，为消息提供了额外的一些信息。包括唯一的标识，目的地，还有关于会话（session）的信息。第一行是消息的方法名（the method name）。接下来是列出的头域。这个例子包含了所需要的头的最小集合。我们将在下面简要的描述这些头域。l VIA：它包含了用户A等待发出请求对应响应的所在地址。还包含了一个叫做“branch”的参数，这个参数用来唯一的标识这个事务（transaction）。VIA头将最近从“SIP跳”（SIP hop）定义为IP，传输，和指定事务参数（The VIA header defines the last SIP hop as IP，transport，and transaction-specific parameters）。VIA专门用来路由响应消息。请求经过的每一个代理都会增加一个VIA头。而对于响应消息而言，相对于再次向定位服务器或是DNS服务器进行定位请求，使用VIA头进行路由将更加容易。l TO：它包含了名字（显示名(display name)）和最初选择的目的地的SIP URI（这里是sip：userB）。TO头域不被用来路由消息包。l FROM：它包含了名字和表明主叫ID（caller ID）的SIP URI（这里是sip：userA）。这个头域有一个tag参数，而这个参数包含了被IP电话添加进URI的一个随机字符串。是被用来进行辨识唯一性的。tag参数被用在TO和FROM头域中。作为一种普遍的机制用来标识对话（dialog），对话是CALLID和两个tag的结合，而这两个tag分别来自参与对话的双方。Tags在并行派生（parallel forking）中作用显著。l CALL-ID：它包含了一个作为这通通话全局性的唯一的标识，而这个唯一标识是有一个随机字符串，来自IP电话的主机名或是IP地址结合而成的。TO，FROM的tag和CALLID的结合完整的定义了一个端到端的SIP关系，这种关系就是我们所知道的SIP对话（SIP dialog）l CSEQ：CSEQ或者称之为命令序列（command sequence）包含了一个整数和一个方法名。CSEQ数对于每一个在SIP对话中的新请求都会递增，是一个传统的序列数。l CONTACT：它包含一个代表直接路由可以联系到用户A的SIP URI，通常是有一个用户名和FQDN（fully qualified domain name）。有时候域名没有被注册，所以，IP地址也是允许使用的。VIA头告诉其他的组件向什么地方发送响应消息，而CONTACT则告诉其他组件向什么地方发送将来的请求消息。l MAX-FORWARDS：它被用来限制请求在到达最终目的地的路径中被允许的最大跳数（hops）。由一个整数构成，而这个整数在每一跳中将会递减。l CONTENT-TYPE：它包含了对内容消息的描述。l CONTENT-LENGTH：它用来告知内容消息的字节数。会话的一些细节，像媒体类型和编码方式并不是使用SIP进行描述的。而是使用叫做会话描述协议（SDP RFC2327）来进行描述。SDP消息由SIP消息承载，就像是一封电子邮件的附件一样。过程如下：话机开始并不知道用户B和负责域B的服务器的位置。因此，它向负责sipA域的服务器发送INVITE消息请求。发送地址在用户A的话机中进行设置或通过DHCP发现。服务器sipA.com也就是我们知道的域sipA.com的SIP代理服务器。1. 在这个例子中，代理服务器收到INVITE请求消息并发送“100 trying”响应消息给用户A，表明代理服务器已经收到了INVITE消息并正在转发这个请求。SIP的响应消息使用一个三个数字组成的数字码和一条描述语句说明响应的类型。并拥有和INVITE请求一样的TO，FROM，CALLID和CSEQ等头域，以及VIA和其“branch”参数。这就使得用户A的话机同发出的INVITE请求联系在一起。2. 代理A定位代理B的方法是向DNS服务器（SRV 记录）进行查询以找到负责sipB的SIP域的服务器地址并将INVITE请求转发给它。在向代理B（译者注：这里作者写的是proxyA，但是应该是B）发送INVITE消息前，代理A将其自己的地址通过VIA头添加进INVITE，这就使得用户A的话机同INVITE请求的响应消息联系在了一起。3. 代理B收到INVITE请求，返回“100 Trying”消息响应，表明其正在处理这个请求。4. 代理B查询自己的位置数据库以找到用户B的地址，然后将自己的地址也通过VIA头域添加进INVITE消息发送给用户B的IP地址。5. 用户B的话机收到INVITE消息后开始振铃。话机为了要表明这种情况（振铃），发送回“180 Ringing”响应消息。6. 这个消息以相反的方向路由通过那两个代理服务器。每一个代理利用VIA头域来决定向哪里发送响应消息并从顶部将其自己的VIA头去除。结果就是，180 Ringing消息不需要任何的DNS查询，不需要定位服务的响应，也不需要任何的状态处理就能够返回到用户那里。这样的话，每一个代理服务器都能够看到由INVITE开始的所有消息。7. 当用户A的话机收到“180 Ringing” 响应消息后开始“回铃”，表明另一端的用户正在振铃。一些话机是通过显示一些信息进行表示的。8. 在这个例子中，用户B对对方发起的通话进行了响应。当用户B响应时，话机发送”200 Ok“响应消息以表明通话被接起。“200 Ok”的消息体中包含了会话的描述信息，这些信息包括指定了编码方式，端口号，以及从属于会话的所有事情。作这项工作的就是SDP协议。结果就是，在从A到B（INVITE）和从B到A（200 OK）的两个阶段，双方交换了一些信息，以一种简单的“请求/响应”的模式协商了在这通通话中所需的资源和所需要的能力要求。如果用户B不想得到这通通话或是此刻处于忙线中，200 Ok将不会发出，取代它的是描述这种状况（这里是486 Busy Here）的消息。第一行是响应码和描述信息（OK）。接下来是头域行。VIA，TO，FROM，CALLID和CSEQ是从INVITE请求中拷贝的。有三个VIA头，一个是用户A添加的，另一个是代理A添加的，最后一个则是代理B添加的。用户B的SIP话机在对话的双方加入了一个TAG参数，这个参数在这通通话的以后的请求和响应消息中都将出现。CONTACT头域中包含了URI信息，这个URI信息是用户B能够直接被联系到他们自己的IP话机的地址。CONTENTTYPE和CONTENTLENGTH头域先给出了关于SDP头的一些信息。而SDP头则包含了用来建立RTP会话的媒体相关的参数。1. 在这个例子中，“200 Ok”消息通过两个代理服务器被送回给用户A，之后用华A的话机停止“回铃”表明通话被接起。2. 最后用户A向用户B的话机发送ACK消息确认收到了“200 Ok”消息。在这里，ACK避开了两个代理服务器直接发送给用户B。ACK是SIP中唯一不需要进行响应的消息请求。两端在INVITE的过程中从CONTACT消息中了解双方的地址信息。也结束了INVITE/200 OK/ACK的过程，这个过程也就是我们所熟知的SIP三次握手。3. 这个时候两个用户之间开始进行会话，他们以用SDP协议协商好的方式来发送媒体包。通常这些包是端对端进行传送的。在会话中，通话方可以通过发送一个新的INVITE请求来改变会话的一些特性。这叫做reinvite。如果re-invite不被接受，那么“488 Not Acceptable Here”响应就会被发出，但是会话不会因此而失败。4. 要结束会话的时候，用户B产生BYE消息来中断通话。这个消息绕过两个代理服务器直接路由回用户A的软电话上。5. 用户A发出“200 OK”响应消息以确认收到了BYE消息请求，从而结束会话。这里，不会发出ACK。ACK只在INVITE请求过程中出现。有些情况下，在整个会话过程中，对于代理服务器来说，能够待在消息传输的中间位置来观察两端的所有消息交互是很重要的。如果代理服务器想在INVITE请求初始化完成后还待在此路径中，可以在请求消息中添加RECORDROUTE头。用户B的话机得到了这个消息，之后在其消息中也会带有这个头，并且会将消息发送回代理。记录路由（Record Routing）在大多数的方案中都会被使用。REGISTER请求是代理B用来定位用户B的方法。当话机初始化的时候或是在通常的时间间隔中，软电话B向在域sipB中的一个服务器（SIP REGISTRAR）发送REGISTER请求。注册服务器（REGISTER）将URI与一个IP地址联系在一起，这种绑定被存储在定位服务器上面的数据库里。通常，注册服务器，定位服务器，和代理服务器在同一台物理机器上，并使用相同的软件。OpenSER就能够扮演这三种角色。一个URI只能够在一个特定的时间内由一个单独的机器注册。SIP事务和对话（SIP Transactions and Dialogs）理解“事务”（transaction）和“对话”（dialog）的区别是非常重要的。事务发生在一个用户代理客户端和另一个用户代理服务端之间，包含从第一请求到最后一个响应的所有消息。中间的阶段性的响应消息可以是以1开头的三位数字码（比如180 Ringing），最终的响应消息则是以2开头的三位数字码（比如 200 OK）。事务包括的范围由SIP消息中VIA头形成“堆栈”来决定。因此，用户代理在初始化invite后才不需要依靠DNS或位置表进行消息路由。对话（Dialog）通常是从INVITE事务开始，由BYE事务结束。一个对话由CALLID头唯一标识。TO tag，FROM tag和CALLID的结合来完整的定义。按照rfc3665的描述，有11个基本的会话建立流程。其列出的并不一定是完整的，但是覆盖了最好的例子。前两个流程在这一章节中进行了阐述“成功建立会话Successful Session Establishment”和“通过两个代理建立会话Session Establishment Through Two Proxies”。其中的一些流程的描述你将在其他阐述呼叫前传（call forwarding）（譬如：“不接听导致没能成功建立Unsuccessful with no Answer”和“忙音导致建立失败Unsuccessful Busy”）的章节中看到。RTP协议（The RTP Protocol）译者注：应为Real Time Transport Protocol实时传输协议是负责诸如音频和视频等数据的实时传输的。它标准化于RFC3550。使用UDP协议进行传输承载。为了能够被实时传输，音频或视频必须经过一定的编码打包。最基本的，该协议允许使用如下的一些特性对进出的数据包的媒体传输的时间和内容要求进行指定：l 序号l 时间戳l 无重传机制的包的前转l 源识别l 内容识别l 同步与RTP相伴的协议叫做RTCP（Real Time Control Protocol），被用作对RTP包进行监控。它可以度量延迟和抖动。编码（Codecs）RTP协议描述的内容通常会由一种编码方式进行编码。没一种编码方式都有一种指定的用途。一些有压缩算法而另外一些则不需要。比较普遍的是使用不需要压缩的G.711编码方式。一个信道64Kbps的带宽要求需要一个高速的网络，通常在局域网（LANs）中比较常见。但是在广域网（WAN）中对于一个单独的声音信道来说，64Kbps的带宽购买起来比较昂贵。这时候诸如G.729和GSM等可以将声音包压缩至8Kbps的编码方法则可以节省很多的带宽。由Global IP sound公司发明的iLBC编码方式则可以掩盖网络中由丢包造成的影响。在丢包率带到7%的情况下，使用iLBC仍然能够维持一个比较好的声音质量。所以对于你的VoIP提供商支持的编码方式你必须进行明智的选择。DTMFRelay在一些情况下，RTP协议被用来承载诸如DTMF的信号信息。RFC2833中描述了一种方法，这种方法就是将DTMF作为RTP协议中的命名事件（named events）进行传输。在用户代理客户端和用户代理服务端之间使用同一种方法进行DTMF传输是非常重要的。实时控制协议（Real Time Control Protocol-RTCP）RTCP可以对接受的质量进行反馈。它为RTP媒体流提供带外控制信息。诸如抖动（Jitter），往返时延（RTTRound Trip Time），传输延迟（latency）和丢包等的数据可以使用RTCP进行搜集。RTCP通常用来对声音质量进行报告。会话描述协议（Session Description Protocol-SDP） SDP协议在RFC4566中被进行了详细的描述。它是在用户代理之间进行会话参数协商之用的。媒体的细节，传输的地址还有其他与媒体相关的一些信息都使用SDP协议在用户代理之间进行交互。通常，INVTIE消息中包含了SDP“供给消息”，而200 Ok则包含了“回答消息”。这些消息会在下面的图中进行展示。在下图中，你可以观察到GSM编码方式被“供给”，但是另外一台话机却并不支持该编码，那么然后它将使用它本身支持的编码方式进行“回答”，在这个例子中它支持的是G.711 ulaw（PCMU）和G.729编码方式。 会话的“rtpmap:101”就是在RFC2833中描述的DTMFrelay信息。INVITE （SDP Offer）200 OK（SDP Answer）SIP协议与OSI七层模型（The SIP Protocol and the OSI Model）理解声音相关协议的每一个协议对于OSI模型是属于哪一层也是相当重要的。VoIP服务提供商的整体框图（The VoIP Provider “Big Picture”）在我们开始深入的挖掘SIP代理之前，了解VoIP提供商的解决方案中的所有部件是非常重要的。服务提供者通常由多个服务器（servers）和多个服务（services）组成。这里说的服务可以根据规模的大小来决定是被安装在一台单独的服务器上还是安装在多台机器上面。本书将在前几个章节中按照这张图从左到右来描述每一个部件。所有的章节中都将使用这张图来帮助你来了解你所处的位置何在。SIP 代理（SIP Proxy）SIP代理是我们解决方案中的核心部件。用来负责用户的注册和维护位置数据库（映射IP和SIP地址）。所有的SIP路由和消息都会被SIP代理处理，它也负责一些用户端级别的服务譬如呼叫前转，白/黑名单，快速拨号等。这个部件从不处理媒体（RTP包），所有与媒体相关的包都从用户代理客户端，服务器和PSDN网关直接路由。用户，管理和供给入口（User，Administration，and Provisioning Portal）用户管理和供给入口是一个重要的部件。在入口当中，用户订阅服务并且应该能够购买信用量，修改密码和验证他/她的账号。另一方面，管理者应该能够删除用户，改变用户信用级别，承认，删除权限。对于管理员来说，“供给（Provisioning）”过程使得用户代理如IP电话，模拟话机适配器还有软电话的自动安装过程更加容易。PSDN 网关（PSDN网关）为了能和公共的交换电话网络交互，PSTN网关是需要的。通常，这个网关是使用E1或T1中继线的PSTN的接口。在这个领域中使用最广泛的是来自Cisco，AudoCodes和Quintum公司的网关。Asterisk也占据了一定的市场份额，因为它的每个端口的价格要比竞争对手们便宜75%。如何评估一个网关的好坏，要检查它对SIP协议扩展的支持程度，譬如对RFC3515（REFER），RFC3891（Replaces）还有RFC3892（Referred by）。这些协议使得我们能够在SIP代理背后进行呼叫转移；如果网关中不支持他们，进行呼叫转移是不太可能的事。媒体服务器（Media Server）因为SIP代理从不处理媒体，所以如IVRs，语音邮箱，电话会议等和媒体相关的服务要能够在媒体服务中得到实现。由iptel开发的SEMS SIP Express媒体服务器具有一些很好的特性，如conference，voicemail和announcements等。我们要再一次提到Asterisk，因为它也能够用来提供这些服务。穿透NAT的媒体代理或RTP代理（Media Proxy or RTP Proxy for Nat Traversal）任何SIP服务提供者必须要为他的客户提供NAT穿透的解决方案。媒体代理就是一座帮助处在对称式防火墙（symmetric firewall）之后的用户能够访问SIP服务提供者进行RTP连接的桥梁。如果没有了这些代理，服务提供者可能会流失35%的用户。你可以使用这些部件来实现一个通用的NAT穿透技术。媒体代理还可以帮助你进行记帐纠错，比如，因为某种原因，没有收到BYE消息而导致了SIP对话没有结束，结果记帐发生了错误等情况。RADIUS记账（RADIUS Accounting）拥有一台安装了RADIUS的服务器是对通话进行记账的基本条件。SIP服务提供者对账单记录是最关心的。OpenSER可以被配置将一些记账信息发送到一台RADIUS服务器（比如Radiator或FreeRADIUS）上。SIP通话账单也可以被记录到数据库中。但是，这样将产生两条记录，而这两条记录需要手工进行核对。用CDRTool计费（CDRTool Rating）RADIUS服务器可以记录关于通话时长的一些信息，但是却不能记录每通通话的资费信息。将资费信息应用到通话上是需要技巧的。这里我们使用AG项目组（）开发的被称为CDRTool的GPL工具。它负责将资费应用到通话上面。监控工具（Monitoring Tools）最后我们需要一些监控，故障检修和测试的工具来帮助我们定位并解决在SIP服务器上发生的一些问题。首当其冲的当然是协议分析工具，在余下的章节中我们将能够看到如何使用ngrep，ethereal和tethereal。OpenSER有一个被称为SIP trace的模块，我们也将使用到。哪儿能够找到更多信息SIP协议最好的参考资料就是RFC3261。阅读RFC确实有点沉闷（不过如果你有点失眠这确实是一种好办法）。你可以在http:/www.ietf.org/rfc/rfc3261.txt上找到它。也可以在哥伦比亚大学的网站上找到好的SIP教程如：http:/www.cs.columbia.edu/coms6181/slides/11/sip_long.pdf。也可以在http:/www.cs.columbia.edu/sip/上找到许多关于SIP的信息。一个非常好的教程在iptel的网站上：http:/www.iptel.org/files/sip_tutorial.pdf。下面是一个叫做SIP应用者（SIP implementors）的邮件列表，你可以在上面就SIP的知识进行提问：https:/lists.cs.columbia.edu/mailman/listinfo/sip-implementors。概要（Summary）这一章你已经学到了什么是SIP协议以及SIP协议的功能。也知道了诸如SIP代理，SIP注册服务器，用户代理客户端，用户代理服务端，PSTN网关等SIP协议中的部件。还看到了SIP的体系结构，主要的消息和处理过程。以及去什么地方可以找到更多相关的信息。第二章：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服务器进行扩展。可以在上查看WeSIP。使用方案（Usage Scenarios）OpenSER主要用来作为SIP代理和注册服务器。但是，它也可以被用于其他的一些应用当中，比如代理分发器（Proxy dispatches），Jabber网关（Jabber Gateway），与媒体网关和RTP代理合作来进行NAT穿透等。支持IPv4和IPv6并且能够支持多域。OpenSER可以被应用在Linux，Solaris，还有FreeBSD等平台。OpenSER本身的创建是为了当作SIP代理服务器使用的。然而，利用它的新的模块，如今，OpenSER能够被用在如下的一些方案中：ModulesFunctionalityDISPATCHER,PATHLoad balancingMEDIAPROXY,RTPPROXY,NATHELPERNat TraversalPRESENCEPresence ServerIMC XMPPInstant Messaging让我们看看OpenSER的大多的使用场景吧。在所有这些场景中，OpenSER就像胶水一样，将所有的SIP部件粘在一起。l VoIP服务提供商l 即时消息服务提供商l SIP负载均衡l 嵌入式IP PBXl NAT穿透l SIP.EDUOpenSER 框架（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（）命令丢弃该消息。billingSIP代理期望的行为（SIP ProxyExpected 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中的新方法。当使用松散路由时，RURI从来都不会被改变，这种方法和之前的旧方法保持向后兼容。（严格路由