设为首页 收藏本站
开启辅助访问 切换到宽版
注册会员 找回密码

VoIP88

toasterisk 发表于 2011-6-12 12:38 | 显示全部楼层 |阅读模式
使用OpenSER构建电话通信系统

Building Telephony Systems with OpenSER

原作者翻译链接:http://blog.csdn.net/speedingboy/archive/2010/08/01/5780670.aspx


第一章: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协议被设计成多媒体框架的一部分,而这种多媒体框架包括RVSP,RTP,RTSP还有SDP等其他协议。然而,SIP却并不依靠其他这些协议工作。



SIP基础(SIP Basics)

SIP在工作的方式上与HTTP协议相类似。SIP的地址像是e-mail的地址。SIP代理中使用的一个比较有趣的特性就是“别名(alias)”,也就是说你可以有多个SIP地址,譬如:

       johndoe@sipA.com

       +554845678901@sipA.com

       45678901@sipA.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@voffice.com.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.com。一种可靠安全的SIP URI也可以被使用,譬如sips:userA@sip.com。使用SIPS建立的通话将会在主叫和被叫之间使用安全可靠的传输机制(TLS-Transport 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@sip.com)。TO头域不被用来路由消息包。

l        FROM:它包含了名字和表明主叫ID(caller ID)的SIP URI(这里是sip:userA@sip.com)。这个头域有一个tag参数,而这个参数包含了被IP电话添加进URI的一个随机字符串。是被用来进行辨识唯一性的。tag参数被用在TO和FROM头域中。作为一种普遍的机制用来标识对话(dialog),对话是CALL-ID和两个tag的结合,而这两个tag分别来自参与对话的双方。Tags在并行派生(parallel forking)中作用显著。

l        CALL -ID:它包含了一个作为这通通话全局性的唯一的标识,而这个唯一标识是有一个随机字符串,来自IP电话的主机名或是IP地址结合而成的。TO,FROM的tag和CALL-ID的结合完整的定义了一个端到端的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,CALL-ID和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,CALL-ID和CSEQ是从INVITE请求中拷贝的。有三个VIA头,一个是用户A添加的,另一个是代理A添加的,最后一个则是代理B添加的。用户B的SIP话机在对话的双方加入了一个TAG参数,这个参数在这通通话的以后的请求和响应消息中都将出现。

CONTACT头域中包含了URI信息,这个URI信息是用户B能够直接被联系到他们自己的IP话机的地址。

CONTENT-TYPE和CONTENT-LENGTH头域先给出了关于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请求来改变会话的一些特性。这叫做re-invite。如果re-invite不被接受,那么“488 Not Acceptable Here”响应就会被发出,但是会话不会因此而失败。



4. 要结束会话的时候,用户B产生BYE消息来中断通话。这个消息绕过两个代理服务器直接路由回用户A的软电话上。



5. 用户A发出“200 OK”响应消息以确认收到了BYE消息请求,从而结束会话。这里,不会发出ACK。ACK只在INVITE请求过程中出现。



有些情况下,在整个会话过程中,对于代理服务器来说,能够待在消息传输的中间位置来观察两端的所有消息交互是很重要的。如果代理服务器想在INVITE请求初始化完成后还待在此路径中,可以在请求消息中添加RECORD-ROUTE头。用户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事务结束。一个对话由CALL-ID头唯一标识。TO tag,FROM tag和CALL-ID的结合来完整的定义。

按照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提供商支持的编码方式你必须进行明智的选择。
DTMF-Relay

在一些情况下,RTP协议被用来承载诸如DTMF的信号信息。RFC2833中描述了一种方法,这种方法就是将DTMF作为RTP协议中的命名事件(named events)进行传输。在用户代理客户端和用户代理服务端之间使用同一种方法进行DTMF传输是非常重要的。
实时控制协议(Real Time Control Protocol-RTCP)

RTCP可以对接受的质量进行反馈。它为RTP媒体流提供带外控制信息。诸如抖动(Jitter),往返时延(RTT-Round 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中描述的DTMF-relay信息。

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.agprojects.com)开发的被称为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的体系结构,主要的消息和处理过程。以及去什么地方可以找到更多相关的信息。
8080 发表于 2011-6-24 10:31 | 显示全部楼层
mark 了慢慢学习,好资料。翻译的作者牛。。。。
xiaomin826 发表于 2012-5-23 22:00 | 显示全部楼层
交流交流好啊!楼主真厉害










时时可爱se 发表于 2012-9-25 08:53 | 显示全部楼层
我也来支持下,非常不错!





您需要登录后才可以回帖 登录 | 注册会员

本版积分规则

关闭

站长推荐上一条 /1 下一条

手机版|VoIP88 ( 粤ICP备11095982号   填写您的邮件地址,订阅我们的精彩内容:

GMT+8, 2017-9-24 18:32 , Processed in 0.309396 second(s), 25 queries .

Powered by VoIP88

© 2001-2017 VoIP88

快速回复 返回顶部 返回列表