第一章 介绍SIP

在我们学习OpenSIPS之前，需要了解一下Sesssion Initiation Protocol(SIP)。本章，我们涵盖以下主题：

  • 了解基础SIP和它的使用
  • 描述SIP架构
  • 解释它相关组件
  • 理解和比较主要SIP消息
  • 解释处理INVITE和REGISTER相关头域
  • 学习SIP处理身份和安全
  • Session Description Protocol和Real-Time Protocol简述

SIP被Internet Engineering Task Force(IETF)建立，并且定义了相关文档称为Request for Comments(RFC). RFC 3261描述了SIP第二版本。SIP是一个应用层协议，用来建立，修改，终止会话或多媒体呼叫。 这些会话可以是语音、视频、电子化学习、聊天、或者屏幕分享。它与Hypertext Transfer Protocol(HTTP)非常相似，设计用来开始、保持和关闭用户间相互通信。如今，SIP协议在Internet Telephony Service Providers(ITSPs), IP PBXs, 语音应用中最为流行。

SIP协议支持五种特性来完成和关闭多媒体会话：

  • User location: 决定终端地址用于通信
  • User parameters negotiation: 决定媒体参数
  • User availability: 决定用户是否有效，是否能完成会话
  • Call establishment: 建立主叫和被叫参数，通知呼叫状态（例如振铃，忙、未发现）给双方
  • Call management: 会员转移和关闭

SIP协议为多媒体架构的一部分，还包含有Resource Reservation Protocol(RSVP), Real-Time Protocol(RTP), Real-Time session Protocol(RTSP), Session Description Protocol(SDP),和Session Announcement Protocol(SAP)，当然没有它独立也可以工作。

理解SIP架构

SIP协议借鉴了很多HTTP协议概念。基于文本协议，使用相同的Digest认证机制。你也将看到类似使用404(Not Found)和301(Redirect)描述错误。由于协议是IETF开发，使用了类似Simple Mail Transfer Protocol(SMTP)地址结构。SIP地址就好像是e-mail地址。另一个有趣的SIP代理特性是别名，你可以拥有多个SIP地址：

在SIP架构中，包含User Agents和servers.SIP通过信令服务器使用peer-to-peer分布式模型.信令服务器仅处理SIP信令，然而User agent和Servers处理信令和媒体，如下图示：

在传统SIP模型，一个user agent通常是SIP phone，通过它的SIP proxy进行通信，图中即通过outgoing proxy(或者它的home proxy)使用INVITE消息发送呼叫。

outgoing proxy查看该呼叫直接送往外部域名。根据RFC 3263，它查找DNS服务器查询目标域名相对应的IP地址。然后，outgoing proxy转发呼叫到DomainB的SIP Proxy。

incoming proxy将查询它的location table，看看agentB的IP地址，如果该地址通过注册插入了location table，那么将呼叫转向agentB。

在收到SIP消息后，agentB将拥有所有需要建立RTP会话（通常是语音）所需要的信息，给agentA发送一个200 OK响应。一旦agentA接收到了agentB的响应。双发媒体就建立了。可以通过发送BYE请求消息来结束会话。

这里，你就能看到SIP架构的主要组件。整个SIP信令流通过SIP Proxy服务器，另一方面，媒体使用RTP协议通过终端直接传输。这些组件可简单描述为如下顺序：

上面图片，你可以看到如下组件：

  • UAC(User Agent Client): 发起SIP信令的client或者终端
  • UAS(User Agent Server): 接收来UAC的SIP信令并响应
  • UA(User Agent):逻辑上的实体可以扮演UAC或者UAS，例如SIP endpoint(IP phones, ATAs, softphones等等)
  • Proxy Server:接收UA的请求，如果特定终端不在自身域名下就转移到另一个SIP代理
  • Redirect Server: 接收请求并响应主叫，响应消息包含目标地址（302， Moved Temporarily)
  • Registrar Server: 提供被叫的contact地址给proxy或者redirect server

proxy, redirect和regisrar服务器通常物理上是同一台服务器或者软件

SIP注册过程

SIP注册过程如下所示：

SIP协议中有个组件叫Registrar，它接收REGISTER请求并保存注册信息到location server。SIP协议具备发现能力；换句话说，如果一个用户与另一个用户开启会话，SIP协议必须能够发现该用户怎样可以到达。发现进程通过Registrar服务器接收请求并且找到要发送的相应位置而结束。基于Registrar服务location数据库进行维护。Registrar服务器可以接收其他类型信息，不仅仅是client的IP地址。也可以接收例如Call Processing Language(CPL)信息。

在话机可以接收呼叫前，它必须注册在location数据库。该数据库，拥有关联话机各自的IP地址。在我们示例中，你可以看到sip用户[email protected]通过200.180.1.1进行注册。

RFC3665定义了实现一个最小功能集SIP IP通信网络最佳实践。在以下表格，根据RFC3665针对registration事务定义的流程。根据RFC3665，有5个关联一个User agent注册进程的基本流程、

消息流程 描述
注册成功：在发送了Register请求后，User agent将会被要请进行密码验证。我们将在第五章-订阅者管理详细描述
更新Contact List:因为不是一个新注册，该消息已经包含了摘要信息，将不会再返回401消息。要改变Contact list，User agent只需要发现一个新注册消息并包含CONTACT头域
当前Contact list请求：在该例子，User agent将发送消息里的CONTACT头域置空，指示user想向服务器查询当前的Contact list。在200 OK消息中，SIP服务器将会发送包含当前contact list的CONTACT头域
取消注册：User agent将会发送带有EXPIRES头域值为0，并且CONTACT头域值为*消息
未成功的注册：UAC发送REGISTER请求并且跟成功注册一样收到了401 Unauthorized消息，在该序列中，它提供了一个hash值尝试注册。服务器，检测该密码不正确，那么将再次发送一个401 Unauthorized消息。该进程将会根据UAC的配置重复几次

SIP 服务器分类

SIP服务器有一些不同分类。依赖应用，你可以在方案中使用一个或所有。OpenSIPS可以扮演proxy，redirect, B2BUA或者是Registrar服务器。

Proxy 服务器

Proxy服务器模式中，所有SIP信令都要通过SIP proxy。该行为可以帮助计费。缺点是中间的代理服务器在SIP会话确立期间有开销。不管SIP服务器的角色，RTP包将直接从一端发送给另一端，SIP proxy也是一样的。

Redirect 服务器

SIP proxy可操作为SIP redirect(重定向)模式。在该模式，SIP服务器将非常伸缩性，因为它不保存transactions的状态，仅仅在收到INVITE消息后，回复UAC 302 Moved Temporarily，然后从SIP dialog中移除。该模式，SIP Proxy占用较少资源，每小时可处理百万呼叫。当你不需要计费时需要高伸缩性时那么这是通用选择。

B2BUA 服务器

Back-to-Back(B2BUA)用来隐藏网络拓扑结构。它对buggy clients不能根据路由表正确路由SIP请求有帮助。许多PBX系统，例如Asterisk、FreeSwitch、Yate等以B2BUA方式工作。

SIP请求消息

有多种请求消息类型。SIP是transactional，通过请求请求和回复通信。最重要的请求类型如下：

大多时，你会使用REGISTER, INVITE, ACK, BYE和CANCEL。一些消息用于其他特性。例如，INFO也用户Dual-tone Multi-frequency(DTMF)传送和呼叫中信令信息。PUBLISH, NOTIFY和SUBSCRIBE提供了呈现系统。REFER用作呼叫转移以及MESSAGE用作聊天应用。根据协议标准进程也会出现新的请求。响应这些请求信息的文本格式和HTTP协议类似。一些重要的回复如下：

SIP dialog 流程

我们假定两个user agents使用如下图示进行消息序列，你可以查看RFC 3665查看其他相关会话建立。

消息标记在序列中。在本例中，userA通过网络使用IP电话呼叫userB IP电话。要完成通话，需要两个SIP代理。

userA呼叫userB使用称为SIP URI的SIP身份呼叫。URI和e-mail地址类似，例如sip:[email protected]。加密的SIP URI为sips:[email protected]。呼叫使用sips:(Secure SIP)将在主叫和被叫中使用加密传输Transport Layer Security(TLS)。

事务开始于userA发送一个INVITE请求给userB。INVITE请求包含一些头域，头域提供了消息的附加信息，包邮唯一标识，目标地址和会话信息。

消息第一行包含了方法名称和request URI。接下就包含了一个头域。本例包含了最小头域所需。头域相关内容描述如下:

  • Method 和 Request-URI: 第一行包含request URI也称为RURI.它包含了当前目的信息，经常倍proxies用来路由请求。在SIP请求中最为重要
  • Via：包含了地址信息指定谁来处理userA请求的响应。还包含了branch参数，用来区分transaction.Via头域定义了上一个SIP hop，transport，和transaction-specific参数。Via用来处理路由回复。每个proxy都会添加Via头域。使用Via头域对于消息往返更容易，这样就不需要再次去查location server或DNS
  • To: 包含被叫的name(display name)和SIP URI，并不作为路由辅助信息
  • From: 包含主叫name和SIP URI。还包含一个随机字符串的tag参数。用来区分目的。tag参数用在To和From域。使用两个 tags连同Call-ID区分dialog的通用机制。
  • Call-ID: 包含了全局唯一标识，通过组合随机字符串，也可能还包含了hostname或者UAC的IP地址。To, From,和CAll-ID tags组合定义了端到端的SIP dialog
  • CSeq: command sequence包含整数和方法名。每个SIP dialog都会增长CSeq数值。
  • Contact: 包含了SIP URI, 通常组合了用户名字和fully qualified domain name(FQDN).通常使用IP地址替代FQDN。如果说Via头域告诉如何发回消息，那么Contacts告知如何像该UA发起请求。
  • Max-Forwards: 用来限制请求最大跳数，每经过一跳都会加一
  • Content-Type: 消息主题描述
  • Content-Length: 包含了消息主题字节数

会话详情描述了媒体类型和编解码，这些信息并没有在SIP中描述，而是使用了Session Description Protocol(SDP)(RFC 2327)描述。该SDP消息由SIP携带，和邮件附件类似。

该话机不知道userB和domainB的位置。所以，它将INVITE请求发送给域名sipA。该地址通过配置userA或者通过DNS发现。服务器sipA.com也即sipA.com下的SIP proxy

流程如下：

  1. 本例中，proxy收到INVITE请求，返回100 Trying给userA，指示着proxy收到了INVITE请求，正在转发请求。SIP使用three-digit码回复，并带有描述语。该响应包含了相同的To, From, Call-ID和CSeq头域，还带了branch参数在Via中。与UserA话机INVITE请求相关联。
  2. ProxyA 通过使用DNS服务器(NAPTR和SRV记录）来定位ProxyB来查找哪个服务器处理SIP域名sipB并且转发INVITE请求。在发送请求到ProxyA前，它将自己的地址放入到了Via头域。INVITE请求已经包含了userA的Via头域
  3. ProxyB收到INVITE请求并响应100 Trying给ProxyA指示请求已经被处理
  4. ProxyB查找自己的location database里userB地址，然后添加另一个包含自己地址的Via头域并转发的userB's IP地址。
  5. userB话机收到INVITE请求并开始振铃。话机响应180 Ringing.
  6. 消息通过两个proxies回传。每个proxy使用Via头域来决定如何响应，并且将自己的Via头域从顶部移除。根据结果，180 Ringing回传不需要查找DNS或Location服务，也不需要状态处理。所以，每个proxy都会收到INVITE请求回复
  7. 当userA的电话接收180 Ringing消息，开始振铃提示用户，有些通过显示来提醒。

  8. 本例中，userB决定接听呼叫。摘机时，话机发回200 OK响应来指示呼叫接听。200 OK 消息包含了消息体，消息体里指明了codec, ports和所有会话相关参数。使用SDP协议来处理。根据结果，A到B(INVITE)和B到A(200 OK)协商能力。如果userB不想接听或者处于忙，那么将不回发200 OK消息，会根据相应情况回复，例如486 Busy Here。

第一行包含了response code和描述语(OK)。包含了Via, To, From, Call-ID, and CSeq头域。有三个Via头域：一个是userA添加的，另一个是ProxyA添加，最后一个是ProxyB添加。userB的SIP话机添加了tag参数至To和From头域，并且在未来的请求和响应都会包含该tag参数。

Contact头域包含了可以直接连接userB的URI

Content-Type和COntent-Length头域提供了关于SDP头域信息。SDP头域包含了构建RTP会话媒体相关参数。

接通后，将发生：

  1. 200 OK消息通过两个proxies到userA,话机停止响铃，指示呼叫接听。
  2. 最终，userA发送ACK 消息给userB话机确认已经收到了200 OK消息。当没有使用record routing的话，ACK会直接从phoneA发到phoneB，不需要proxies.ACK是唯一一个没有回复的SIP方法。终端从CONTACT头域知道双方地址。INVITE/200 OK/ACK，也即SIP的三次握手。
  3. 此刻，两个两个用户开始了会话，双方通过交换的SDP信息来发送媒体包。通常，这些包直接端到端。会话期间，参与者可以通过更改会话参数发起一个新的请求，称为reinvite.如果不接收reinvite，将会收到488 Not Acceptable Here消息，不过会话不会因此断开
  4. 在会话结束，userB通过发送BYE消息来终止。整个消息通过userA的SIP电话直接路由，绕过两个proxies
  5. userA回复200 OK消息确认收到BYE消息请求来结束会话。不需要再发ACK。ACK只在INVITE请求中发送

在某些情况下，proxies在整个会话中看到所有信令非常重要。如果proxy向在初始化INVITE请求扔保存在路径中，可以通过添加Record-Route在头域来强制要求信令回传。如果没有record-routing，就不能呼叫计费。

REGISTER请求使ProxyB得知userB的location。当话机初始化，或者在周期时间中，SIP phoneB发送REGISTER请求到domain的SIP B。REGISTER消息关联URI([email protected])的地址。绑定保存在location server。通常Registrar，Location和Proxy都在同一台服务器，OpenSIPS就是如此。URI只能同一时间注册在一个设备。

SIP transactions和dialogs

理解transaction和dialog之间的区别非常重要。OpenSIPS脚本的使用会用到它们。例如，在transactions拥有属性值对，dialog有很多变量。如果你不能区分dialog和variable，你就很男去配置SIP服务器。

transaction发生在user agent客户端和服务端从请求到响应构成的所有消息（包含所有临时响应）。transaction作用域定义在了SIP消息Via头域，所以user agents在初始化invite之后，不需要依赖DNS或者location tables来路由消息。

ACK请求是个特殊例子。对于positive回复(2XX)，UAC创建一个新的transaction，生成一个新的CONTACT头域，通过绕过proxy的方式直接发送给UAS。然后，对于nagative回复，它属于INVITE transaction，因为不可能在另一部分创建一个不带CONTACT新transaction。这种情况下，请求和INVITE一样发往相同proxy。

根据RFC3261, 一个dialog表示有时两个user agent的peer-to-pee SIP关系。dialog通过dialog ID标示定义在每个UA，拥有Call-ID值，local tag, 和remote tag在各自From和To头域中。

dialog通过transactions创建、保持、结束。所有dialog都由一个transaction构建，有可能还有个transaction去改变(mid-transaction)。此外，可能会没有end-dialog transaction。（有时dialog基于超时结束的）

根据RFC 3655，有11个基本会话流程。虽然不是完全，但涵盖了最佳实践。前两我们已经在本章谈及，通过两个proxies的Successful Session Establishment和Session Establishment。其他一些我们会再“第11章 -实现SIP Services”见到它们。

定位SIP服务器

和邮件服务器一样，你需要指定哪个服务器服务相关domain。SIP 服务器定位描述在RFC3263。首要责任是决定IP，端口和传输协议。其次是proxy的备份地址。

要实现这些目标，我们将使用一个Domain Name System，更准确的是说：Name Authority Pointer(NAPTR)和Service(SRV)记录。 NAPTR记录用来决定传输协议。要制定传输协议，你应该插入一条DNS记录到DNS服务器的zone文件。在下面的代码中，我们针对该domain开启了三个协议，TLS, TCP和UDP.如果客户端执行TLS和UDP，根据定义顺序会使用TLS。

Order pref flags service regexp replacement IN NAPTR 10 50 "s" "SIPS+D2T" "" _sips._tcp.opensips.org. IN NAPTR 20 50 "s" "SIP+D2T" "" _sip._tcp.opensips.org. IN NAPTR 30 50 "s" "SIP+D2U" "" _sip._udp.opensips.org.

在选择了传输协议后，那么要选择优先服务器

Service TTL Class P/W Port Server _sips._tcp.opensips.org. 86400 IN SRV 0 5 5060 sipA.opensips.org. _sips._tcp.opensips.org. 86400 IN SRV 0 5 5060 sipB.opensips.org. _sip._udp.opensips.org. 86400 IN SRV 0 5 5060 sipA.opensips.org. _sip._udp.opensips.org. 86400 IN SRV 0 5 5060 sipB.opensips.org.

包含如下：

  • Service: 服务取名
  • TTL: DNS的time to live
  • Class: 标准DNS类别字段 (总是IN)
  • Priority: 目标主机的优先级，越低就约优先
  • Weight: 同样优先级的记录权重
  • Port: TCP或UDP端口
  • Target: 机器提供服务的hostname

SRV记录的配置通常提供了SIP服务器之间的failovers和load sharing。

SIP 服务

基于发起和接收呼叫，你可以实现一系列SIP服务。这些服务包含（不限于）Call Transfer，Call Pickup， Call Hold和Call Forward和许多其他。幸好、RFC5359(SIP 服务)定义了实现这些任务标准方法。大多的SIP phone实现了这些方法的服务。然后，要实现这些，你要确保所有网络相关组件实现了RFCs制定相关标准。例如，RFC3515定义支持call transfer的REFER方法，以及RFCs 3891和3892分别定义的Referred-By和替换头域，如果你打算使用sip proxy提供PBX-like服务，你必须确保所有组件，甚至是phones和网关都支持。SIP服务实现在phones,gateways,media servers和sip proxies。所有的组件需要相互合作来支持这些特别服务。以下是RFC 5359定义一些服务

  • Call Hold
  • Consulation Hold
  • Music on Hold
  • Transfer - Unattended
  • Transfer - Attended
  • Transfer - Instant Messaging
  • Call Forwarding - Unconditional
  • Call Forwarding - Busy
  • Call Forwarding - No Answer
  • 3 - Way Conference - Third Party is Added
  • 3 - War Conference - Third Party Joins
  • Find - Me
  • Incoming Call Screening
  • Outgoing Call Screening
  • Call Park
  • Call Pickup
  • Automatic Redial
  • Click to Dial

有些可能这里没有列举，请参考RFC相关详情。

SIP 身份

SIP 服务器通常用来提供电话服务。然而，Public Switched Telephone Network(PSTN)并不支持包含域名和字符串的SIP地址。要区分到PSTN的呼叫身份，创建相关方法。

draft-ietf-sip-privacy-04文档描述了Remote-Party-ID头域。虽然并没有设为标准，却广泛用在了网关和SIP服务提供商。看看下面例子：

Remote-Party-ID: "John" sip:[email protected]; party=calling; id-type=subscriber; privacy=full; screen=yes

前面的头域设置了主叫ID号码 +554833328560，呼叫名称为"John"，proxy中属于subscriber，身份已经验证过了(screen=yes)，号码不显示在终端(privacy=full)。草案制定了附加特性来处理privacy请求。Remote-Party-IDs将作为用户caller ID呈现。

标准处理主叫IDs和privacy在后来的RFC3325描述，它定义了P-Asserted-Identity, P-Preferred-Identity, 和Privacy头域名，如下：

P-Asserted-Identity: "John" sip:[email protected] P-Asserted-Identity: tel:+554833328560

要指定caller ID呈现在PSTN，你可以使用这些头。网关应该匹配caller ID和privacy类型。在OpenSIPS 服务器，你可以通过使用append_hf命令来添加头域。它是衍生的RFC，你可以查看文档看看详情。

RTP协议

Real-Time Protocol(RTP)用来处理实施媒体传输，例如音频和视频。RFC 3550定义了标准。它使用UDP作为传输协议。为传输，音频和视频需要通过codec进行分包。大致定义了如下内容：

  • 序列号
  • 时间戳
  • 包传输不进行重发
  • 源身份
  • 内容身份
  • 同步

Codecs

codec使用用来编码和解码数字码。RTP协议内容通常通过codec编码。每个codec之间都有差异。有些有压缩，有些没有。G711仍然是最流行的codec，它没有使用压缩。每个channel使用64Kbps，它需要告诉网络，大部分使用在Local Area Networks(LANs)。然后，在Wide Area Networks(WANs)，64Kbps单个channel来说是相当昂贵的。G.729和GSM codec可以将包压缩至8Kbps,节省了大量带宽。要选择一个语音codec，下面的表提供了相关辅助。带宽没有考虑底层协议的头域。还有相关的视频codec，例如H.264和Google的VP8

Codec Bandwith MOS Env. When to use
G.711 64 Kbps 4.45 LAN/WAN 高质量
G.729 8 Kbps 4.04 WAN 节省带宽，保证质量
G.722 64 Kbps 4.5 LAN 高质量
OPUS 6-510 Kbps --- INTERNET 从窄宽到高质量

还有一些其他编码，例如G.723, GSM, iLBC和SILK。它们对比OPUS都有些失真。OPUS被WebRTC标准所采纳。当然，你可以深入了解更多关于这些编码细节，贯穿整书，将会使用表中所描述的四中codec。MOS是Mean Opinion Score,用来定义语音质量

| 5 | Excellent | Imperceptible | | 4 | Good | Perceptible but not annoying | | 3 | Fair | Slightly annoying | | 2 | Poor |Annoying | | 1 | Bad | very annoying |

DTMF-relay

在VoIP网络中有三种携带DTMF方式：inband的语音模式, RFC 2833定义的RTP命名events，使用SIP INFO信令。RFC 2833描述了使用RTP协议的命名events传输DTMF。在user agent服务器和客户端使用相同方法非常重要。

Session Description Protocol

Session Description Protocol(SDP)定义在RFC4566。用来协商user agents之前的会话参数。媒体详情，传输地址，其他媒体相关信息均使用SDP协议描述。通常，INVITE消息和200 OK消息包含SDP信息。这些消息如下所示。你可以观察到该SDP描述提供了GSM编码，但是其他话机不支持它，然后回复了支持的编码，本例中是G.711 u-law(PCMU)和G.729. rtpmap:101是在RFC 2833中定义DTMF relay。

SIP协议和OSI模型

理解语音各个协议对应OSI模型位置相当重要。以下图示很清晰描述了相应关系：

VoIP provider伟大宏图

本书定位构建VoIP provider。在我们深入SIP proxy前，有必要了解VoIP provider解决方案中各组件。VoIP provider通常由几个服务组合。这些服务可以部署在一个服务器上或者好几个服务器上，取决了容量需求。

本书中，我们将涵盖所有这些组件，从左到右。以下图来帮你标注所处的位置。

SIP proxy

SIP proxy是解决方案中的中央组件。它的职责是用户注册，维持location database(映射IP到SIP地址）。整个SIP路由和信令由SIP proxy处理，也负责处理end-user服务，例如call forwarding, white/blacklist，speed dialing等等。该组件不处理媒体(RTP包)，大部分媒体相关的包直接通过user agents clients , servers 或PSTN网关之间直接传送。

user administration和provisioning portal

一个重要组件是user administration和provisioning portal.在portal，用户可以进行充值，更改密码，验证账号等操作。 另一方面，管理员应当可以删除用户，更改用户余额，赋予或移除权限。Provisioning是提供给user agents的IP phones，analog telephony adapters和SIP phones自动安装。

PSTN 网关

要和PSTN通讯，必须有个PSTN网关，除非你有个SIP trunk。PSTN接口使用E1和T1 trunks。要评估是否好网关，检查支持的SIP扩展，例如RFC 3325(Identity), RFC 3515(REFER)，RFC 3891(Replaces), 和RFC 3892(Referred-by)。这些协议将SIP proxy允许缺席转移，网关没有的话，就不能支持呼叫转移。

媒体服务器

SIP proxy 不处理媒体。Interactive Voice Response (IVR), voicemail, conference, 或者其他相关媒体都应该在媒体服务器中实现。有很多SIP服务器支持该目的，例如Asterisk, FreeSWITCH, Yate, IPTEL的SEMS, AG project的SilkServer.本例中将使用Asterisk，就目前来说最为流行。

media proxy或者RTP proxy的NAT穿越

所有的SIP provider都要为customers处理NAT穿越。media proxy是RTP bridge来帮助处理symmetric防火墙。如果没有的话，将不能处理大部分呼叫，你使用这些组件实现统一NAT穿越技术。media proxy可以帮你纠正未结束的SIP dialogs计费，例如，有时没有发送BYE消息

Accounting和CDR生成

Authenication, Authorization, 和Accounting(AAA)服务器可以和OpenSIPS工作。FreeRADIUS是一个通用选择。在有些时候，你可以不使用RADIUS，直接使用SQL accounting.计费时，会为呼叫生成CDR.

监控工具

最后，我们需要monitoring, troubleshooting，和testing tools来帮助debug SIP服务器问题。第一工具是协议分析，我们将使用ngrep, Wireshark和TShark。OpenSIPS有个模块叫做SIP trace，我们将会在后面使用。

更多参考

最好的参考资料是RFC 3261。读RFCs可能会感觉无聊犯困（在你失眠时很有用）。你可以查看http://www.ietf.org/rfc/rfc3261.txt.

OpenSIPS的mailing lists在http://www.opensips.org/Support/MailingLists.

有个mailing list你可以提交问题给SIP implementors https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors.

总结

本章，我们学习了SIP协议以及它的功能。我们看到了不同的SIP组件，例如SIP proxy, SIP Registrar, user agent client, user agent server和PSTN网关。我们也了解了SIP架构和主要的消息以及流程。

下一章，我们将介绍OpenSIPS和它基本架构以及组件。