使用OpenSER构建电话通信系统——第一章（1）

注：以下文章如需转载，请注明所属作者，转载地址，谢谢！

前言：openser已经成为opensips项目，但是本书的内容绝大部分是适合于学习相关知识的。所以还是针对原书原封不动的做的翻译。

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

 

SIP基础（SIP Basics）

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

      

      

      

在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用户[e-mail]注册到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代理，即使只是利用非常少的资源也可以每小时传送上百万的通话。当你需要的规模很大并且不需要对通话计费的情况下，这种模式通常会被使用。