使用OpenSER构建电话通信系统

使用OpenSER构建电话通信系统

BuildingTelephonySystemswithOpenSER

第一章：SIP介绍(IntroductiontoSIP)

本章结束的时候你将能够：

•描述SIP是什么

•描述SIP是干什么的

•描述SIP的框契

•解释SIP要紧部件的意义

•懂得并比较要紧SIP消息

•描述INVITE与REGISTER请求消息头部的处理过程

在建立与关闭多媒体通话的过程中，SIP协议支持五种要素。

•用户定位(Userlocation)

•用户参数协商：Userparametersnegotiation)

•用户口J用性(Useravailability)

•通话建立(Callestablishment)

通话管理(Callmanagement)

SIP协议被设计成多媒体框架的一部分，而这种多媒体框架包含RTSP,

RTP,RTSP还有SDP等其他协议。然而，SIP却并不依靠其他这些协议工作。

SIP基础(SIPBasics)

在SIP的体系结构中，有多个用户代理与提供不一致服务的服务器。SIP使

用点对点(peer・to-peer)的分布模型来与服务器进行消息的交互。服务器只进

行消息(signaling)的处理，而用户代理的客户端与服务端既能够处理消息也能

够处理媒体。下面的图描述了这样的一个体系：

SIPTrapezoid

SIP

SIP

RTP

UseragentA@DomainAUseragentB@DomainB

startingthecallreceivingthecall

在SIP模型中，用户代理，通常是一台SIP话机与它的SIP代理进行交互,

从上图能够看到,外呼代理(outgoingproxy)将使用INVITE消息向外发出通

话请求。

外呼代理将观察这通通话是否是被定向到外部的域名。然后它将向DNS服

务器发出请求将目标域名解析为对应的IP地址。然后再将通话请求发送给

DomainB对应的SIP代理。

呼入代理(incomingproxy)将在地址列表(locationtable)中查询agentB

的IP地址。假如在地址列表这个地址与之前在注册过程中的IP地址对应，那么

呼入代理就能够定位这个地址了。现在就能够使用这个地址将通话请求发送到

agentB了。

agen旧收到这个SIP消息后(INVITE),就拥有了能够与agentA建立RTP

会话(通常是音频方面的会话)所需要的信息。使用BYE消息能够终止这个会

话。

SIP代理在VoIP提供者里的作用/上卜文(SIPProxyinthe

ContextofaVoIPProvider)

通常VoIP服务的提供者们并不可能实现像上幅图那样的纯粹的SIP四边形

结构，他们不可能同意你向一个外部的域名发送通话请求，由于假如这样，那么

将影响他们的收入(revenuestream)。取而代之的是一个接近三角形的SIP网

络结构。(如下图所示)

VoIPProviders

UseragentA@DomainAUseragentB@DomainA

startingthecallreceivingthecall

SIP工作原理(SIPOperationTheory)

在上图中，你能够看到SIP体系结构中的要紧的构成部件。所有的SIP消息

都会通过SIP代理服务器。另一方面，由RTP协议承载的媒体流则是从一瑞直

接流向另•端。我们将在下面的列表中简要的对其中的•些构成部件进行解释。

•用户代理客户端(UACuseragentclient)——发起SIP消息的客户

端或者终端

•用户代理服务端(UASuseragentserver)——对接收到的从用户代

理客户端发起的SIP消息进行相应的服务端。

•用户代理(UAuseragent)——SIP终端(IP电话，电话适配器(ATA),

软电话(softphone))

•代理服务器(ProxyServer)——从用户代理接收请求，同时假如指定

的被请求的终端不在其域中时，会将请求发送给另外的SIP代理。

•重定向服务器(RedirectServer)——接收请求，但是不直接发送给

被叫用户，而是向主叫方发送目的地址的信息。

•定位服务器(LocationServer)------向代理服务器与重定向服务器提

供被叫者的联系地址。

通常，物理上，代理服务器，重定向服务器与定位服务器存在于同一台

电脑与软件中。

SIP注册过程(SIPRegistrationProcess)

LocationRegistersip:

DatabaseFrom:sip:8500@

tosip:8500@

Contact:<sip:200,180.1.1>

Expires3600

SIP/2.0200OK

SIP协议中使用了一个构件叫做注册服务器。它不仅能够接收REGISTER

消息请求，还能够将收到的消息包中的信息储存到管理对应域名的定位服务器上

面。SIP协议具有发现能力；换句话说，就是假如一个用户要与另外一个用户开

始会话，那么SIP协议务必要发现这个用户能够到达的主机存在。由于定位服

务器能够收到请求消息并找到向什么地方发送，因此这个发现过程由定位服务器

来完成。而这则是基于管理每个域的定位服务器保护着一个定位数据库的事实来

实现的。注册服务器不仅能够接收客户端的IP地址，还能够接收其他类型的消

息。比如，能够收到服务器上面的CPL(CallProcessingLanguage)脚本。

RFC3665定义实现了一个最小的功能集合，这是使得SIP进行IP网络交互

时的最好实践。下面的图就是根据RFC3665中的描述所画出的注册事务处理流

程。

SIPRegistrationFlows

Usera陶］Sip

AgentONewregistration；:PProxy

REGISTER.

.401Unauthorized

REGISTER4

.200OK______________

UpdateofContactList

_____________REGISTER上

<200OK______________

RequestforCurrentContactList

REGISTER»

.200OK

Cancellationoftheregistration

_____________REGISTER.

.200OK______________

UnsuccessfullRegistration

_____________REGISTER上

.401Unauthorized

REGISTER»

401Unauthorized

按照rfc3665中所说，与注册一个用户代理的过程有关的有五个基本的流程,

如下所述：

1.一个新的成功的注册(Asuccessfulnewregistration)----用户代理在发送Register请求后，

将收到认证过程的挑战。我们将在阐述验证过程的章W中看到这个过程的细|九

2.联系列表的更新(Anupdateofthecontactlist)——山丁•不再是新的注册，消息中已经包含了

摘要(digest),那么不可能返回401消息。为了改变联系列表，用户代理仅仅需要发送一条

在CONTACT头中带有新的联系信息的注册信息即可。

3.请求获得当前的联系列表——在这种情况下，用户代理将把发送消息中的CONTACT头置空，

说明用户希望向胭务器询问当前的联系列表。在回复的2000K消息中，SIP服务器将把当前

的联系列表放在其CONTACT的头中。

4.取消注册(Cancellationofaregistration)——用户代理在发送的消息中将EXPIRES头置成0.

同时将CONTACT头设置为“*”表示将此过程应用到所有存在的联系信息。

5.不成功的注册(UnsuccessfulRegistration)——用户代理客户端(UAC)发送一条Register

请求消息，收到一条“401Unauthorized”消息，事实上，这个过程同成功注册过程相同。但是

接下来，它进行哈希运算尝或进行认证。而服务器检测到的是一个无效的密码，继续发送“401

Unauthorized”消息。这个过程•直重复直到重复次数超过在UAC设置的最大值。

作为SIP代理运转的服务器(ServerOperating

asaSIPProxy)

在SIP代理模式下，所有的IP消息都要通过SIP代理。这种行为在向诸如

计费(billing)的过程中帮助很大，而且迄今为止，这也是一种最普遍的选择。

但是它的缺点就是在会话建立过程中的所有的SIP交互中，服务器造成的额外

开销也是客观的。要记住的是，即使服务器作为SIP代理在工作时，RTP包也

总是直接从一端传送到另一端，而不可能通过服务器。

Proxy

INVITELocationeINVITE

sip:8500@Registrarsip:8500@68

From:sip:2400@ServerFrom:sip:24OO@

Tb:sip:8500@To:sip:8500@

CalHD2400@Call-ID2400@

0K2000K200

From:sip:2400@From:sip:24OO@

lb:sip:8500@To:sip:8500@

CaIMD2400@Call-ID2400@

sip:2400@sip,comMediaFlowsip:8500@68

作为SIP重定向运转的服务器(Server

OperatingasaSIPRedirect)

SIP代理能够运行在SIP重定向模式。在这种模式下，SIP服务器的处理量

是相当巨大的，由于它不需要保持事务处理的状态。在对INVITE消息进行初始

化后，仅仅向UAC回复一条“302MovedTemporarily”消息就能够离开SIP对话

(dialog)了。在这种模式下的SIP代理，即使只是利用非常少的资源也能够每

小时传送上百万的通话。当你需要的规模很大同时不需要对通话计费的情况下，

这种模式通常会被使用。

INVITE

sip:8500@

From:sip:2400@Location,

Tb:sip:8500@Registrar,and

Call-ID2400@Redirect

Server

OK302movedtemporarily

Contactsip:8500@200,180.4.168

INVITE8500@200・180,4・168

OK200

ACK8500@68

sip:2400@MediaFlowsip:8500@68

基本消息(BasicMessages)

在SIP环境中会被发送的某本的消息有:

SIPbasicmessages

MethodDescriptionRFC

ACKAcknowledgeanINVITERFC3261

BYETermlnatoanoxistingsessionRFC3261

CANCELCancolapendingroquottRFC32S1

INFOMid-callsignalinginformationRFC2976

INVITESessionestablishmentRFC3261

MESSAGEInstantmessagetransportRFC3428

NOTIFYSendInformationaftersubscribeRFC3265

OPTIONSQuorythecapabilitiesofth。UARFC3261

PRACKAcknowledgeaprovisionalresponseRFC3262

PUBLISHUploadstatusInformationtotheserverRFC3903

REGISTERRegistertheuseranupdatethelocationUbleRFC3M1

REFERA$kanotherUAtoactuponURIRFC3515

SUBSCRIBEEstablishasessiontoreceivefutureupdatesRFC3265

UPDATEUpdatesessionstateinformationRFC3311

大多数时间内，你会使用到REGISTER,INVITE,BYE还有CANCELo而另外•些

消息会被用在其他的特性当中。举例来说，INFO被用在DTMFrelay与通话中消息信息

(mid-callsignalinginformation)<,PUBLISH,NOTIFYSUBSCRIBE则用来支持列席系

统(presencesystems).REFER用来进行通话转接(calltransfer)而MESSAGE则应用

于一些聊天应用程序中。更新的消息也会随着协议标准化进程而随之出现。

ResponseCodes

DescriptionCodeExamples

Informationalor1XX100Trying182Queued

provisionalresponse180Ringing

181CallIsBeingForwarded

Success2XX200OK

202Accepted

Redirect3XX300MultipleChoices303SeeOther

301MovedPermanently305UseProxy

302MovedTemporarily380AlternativeService

ClientErrors4XX400BadRequest411LengthRequired

401Unauthorized413RequestEntityTooLarge

402PaymentRequired414RequesbURITooLarge

403Forbidden415UnsupportedMediaType

404NotFound420BadExtension

405MethodNotAllowed480Temporarilynotavailable

406NotAcceptable481CallLeg/TransactionDoesNotExist

407ProxyAuthentication482LoopDetected

Required483TooManyHops

408RequestTimeout484AddressIncomplete

409Conflict485Ambiguous

410Gone486BusyHere

ServerErrors5XX500InternalServerError503ServiceUnavailable

501NotImplemented504GatewayTime-out

502BadGateway505SIPVersionnotsupported

GlobalErrors6XX600BusyEverywhere604Doesnotexistanywhere

603Decline606NotAcceptable

SIP对话流程(SIPDialogFlow)

这一节将通过一个简单的例子来介绍一些基本的SIP操作。先让我们来诊视下图展示

的两个用户代理之间的消息顺序。你能够看到伴随这RFC3665描述的会话建立过程还有几

个其它的流程。

INVITE(I)

INVITE(3)t

.100Trying(2)INV1TE(5)

100Trying(4)

.180Ringing⑹

.180Ringing(7)

180Ringing(8)200OK⑼

6).200OK(10)<8--------

.200OK(10)

DeviceACK(11)Device

(phone)(phone)

userA.MediaSessionRTP(12).userB

BYE(13)

200OK(14)

A

我们在这些消息上标上了序号。在这个例子中用户A使用IP电话向网络上的另外一台

IP电话发出通话请求。为了完成通话，使用了两个SIP代理。

事务(transaction)的建立始于用户A向用户B发送INVITE请求消息。INVITE请求

中包含一些特定头域。这些头域被称之为属性，为消息提供了额外的一些信息。包含唯一的

标识，目的地，还有关于会话(session)的信息。

INVITEfromA->B

INVITEsip:userB@sipB.comSIP/2.0

Via:SIP/2.0/UDPmoon.sipA.com;branch=z9hG4bK776asdhds

Max-Forwards:70

To:userB<sip:userB@sipB.com>

From:userA<sip:userA@sipA.com>;tag=1234567890

Call-ID:a84b4c76e66710@moon.sipA.com

CSeq：314159INVITE

Contact:<sip:userB@sun.sipB.com>

Content-Type:application/sdp

Content-Length:142

(SDPnotshown)

第一行是消息的方法名(themethodname)。接下来是列出的头域。这个例子包含了

所需要的头的最小集合。我们将在下面简要的描述这些头域。

•VIA：它包含了用户A等待发出请求对应响应的所在地址。还包含了一个叫做

"branch”的参数，这个参数用来唯一的标识这个事务(transaction)oVIA头将最近

从“SIP跳”(SIPhop)定义为IP,传输，与指定事务参数(TheVIAheaderdefines

thelastSIPhopasIP,transport,andtransaction-specificparameters)oVIA专

门用来路由响应消息。请求通过的每一个代理都会增加一个VIA头。而关于响应消

息而言，相关于再次向定位服务器或者是DNS服务器进行定位请求，使用VIA头

进行路由将更加容易。

•CALL-ID：它包含了一个作为这通通话全局性的唯一的标识，而这个唯一标识是有

一个随机字符串，来自IP电话的主机名或者是IP地址结合而成的。TO,FROM的

tag与CALL-ID的结合完整的定义了一个端到端的SIP关系，这种关系就是我们

所明白的SIP对话(SIPdialog)

•CSEQ：CSEQ或者者称之为命令序列(commandsequence)包含了一个整数与

一个方法名。CSEQ数关于每一个在SIP对话中的新请求都会递增，是一个传统的

序列数。

•CONTACT：它包含一个代表直接路由能够联系到用户A的SIPURI,通常是有一

个用户名与FQDN（fullyqualifieddomainname）。有的时候候域名没有被注册，

因此，IP地址也是同意使用的。VIA头告诉其他的组件向什么地方发送响应消息，

而CONTACT则告诉其他组件向什么地方发送将来的请求消息。

•MAX-FORWARDS：它被用来限制请求在到达最终目的地的路径中被同意的最大

跳数（hops）。由一个整数构成，而这个整数在每一跳中将会递减。

•CONTENT-TYPE：它包含了对内容消息的描述。

•CONTENT-LENGTH：它用来告知内容消息的字节数。

会话的一些细节，像媒体类型与编码方式并不是使用SIP进行描述的。而是使用叫做

会话描述协议（SDPRFC2327）来进行描述。SDP消息由SIP消息承载，就像是一封电子

邮件的附件一样。

过程如下:

1.在这个例子中，代理服务器收到INVITE请求消息并发送“100trying”响应消息给

用户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收至I」INVITE请求，返回“100Trying”消息响应，说明其正在处理这个请求。

4.代理B查询自己的位置数据库以找到用户B的地址，然后将自己的地址也通过

VIA头域添加进INVITE消息发送给用户B的IP地址。

5.用户B的话机收到INVITE消息后开始振铃。话机为了要说明这种情况(振铃),

发送回“180Ringing”响应消息。

6.这个消息以相反的方向路由通过那两个代理服务器。每一个代理利用VIA头域来

决定向哪里发送响应消息并从顶部将其自己的VIA头去除。结果就是，180Ringing

消息不需耍任何的DNS查询，不需耍定位服务的响应，也不需要任何的状态处理就

能够返回到用户那里。这样的话，每一个代理服务器都能够看到由INVITE开始的

所有消息。

7.当用户A的话机收到的80Ringing”响应消息后开始“回铃”，说明另一端的用户

正在振铃。些话机是通过显示些信息进行表示的。

8.在这个例子中，用户B对对方发起的通话进行了响应。当用户B响应时，话机

发送"200Ok“响应消息以说明通话被接起。“2000k”的消息体中包含了会话的描述

信息，这些信息包含指定了编码方式，端口号，与从属于会话的所有情况。作这项

工作的就是SDP协议。结果就是，在从A到B(INVITE)与从B至ijA(200OK)

的两个阶段，双方交换了一些信息，以一种简单的“请求/响应”的模式协商了在这通

通话中所需的资源与所需要的能力要求。假如用户B不想得到这通通话或者是此刻

处于忙线中，200Ok将不可能发出，取代它的是描述这种状况（这里是486Busy

Here）的消息。

Response200Ok

SIP/2,0200OK

Via:SIP/2.0/UDPsipB.com

;branch=z9hG4bKnashds8;received=

Via:SIP/2.0/UDPmoon.sipA.com

;branch=z9hG4bK77ef4c2312983.1;received=

Via:SIP/2.0/UDPphoneA.sipA.com

;branch=z9hG4bK776asdhds：received=

To:userB<sip:userB@sipB.com>;tag=a6c85cf

From:userA<sip:userA@sipA.com>;tag=1928301774

Call-ID:a84b4c76e66710@phoneA.sipA.com

CSeq:314159INVITE

Contact:<sip:userB@>

Content-Type:application/sdp

Content-Length:131

第一行是响应码与描述信息（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.在这个例子中，“2000k”消息通过两个代理服务器被送回给用户A,之后用华A的

话机停止“回铃”说明通话被接起。

2.最后用户A向用户B的话机发送ACK消息确认收到了“200Ok”消息。在这里，ACK

躲开了两个代理服务器直接发送给用户B°ACK是SIP中唯一不需要进行响应的消息请求。

两端在INVITE的过程中从CONTACT消息中熟悉双方的地址信息。也结束了INVITE/200

OK/ACK的过程，这个过程也就是我们所熟知的SIP三次握手。

3.这个时候两个用户之间开始进行会话，他们以用SDP协议协商好的方式来发送媒体

包。通常这些包是端对端进行传送的。在会话中，通话方能够通过发送一个新的INVITE请

求来改变会话的一些特性。这叫做re—inviteo假如re-invite不被同意，那么"488Not

AcceptableHere”响应就会被发出，但是会话不可能因此而失败。

4.要结束会话的时候，用户B产生BYE消息来中断通话。这个消息绕过两个代理服务

器直接路由回用户A的软电话上。

5.用户A发出“2000K”响应消息以确认收到了BYE消息请求，从而结束会话。这里,

不可能发出ACKoACK只在INVITE请求过程中出现。

有些情况下，在整个会话过程中，关于代理服务器来说，能够待在消息传输的中间位置

来观察两端的所有消息交互是很重要的。假如代理服务器想在INVITE请求初始化完成后还

待在此路径中，能够在请求消息中添加RECORD-ROUTE头。用户B的话机得到了这个

消息，之后在其消息中也会带有这个头，同时会将消息发送回代理。记录路由(Record

Routing)在大多数的方案中都会被使用。

REGISTER请求是代理B用来定位用户B的方法。当话机初始化的时候或者是在通常

的时间间隔中，软电话B向在域sipB中的一个服务器(SIPREGISTRAR)发送REGISTER

请求。注册服务器(REGISTER)将URI与一个IP地址联系在一起，这种绑定被存储在定

位服务器上面的数据库里，通常，注册服务器，定位服务器，与代理服务器在同一台物理机

器上，并使用相同的软件.OpenSER就能够扮演这三种角色。一个URI只能够在一个特定

的时间内由一个单独的机器注册。

S工P事务与对话(SIPTransactionsand

Dialogs)

TransactionsandDialogs

INVITE(I)

INVITE(3)

.100Trying⑵INVITE⑸

<100Trying⑷

180Ringing(6)-Transaction

<180Ringing(7)

180Ringing(8)200OK(9)

200OK(10)

200OK(10)-Dialog

ACK(11)

MediaSessionRTP(12)

BYE(13)

200OK(14)-Transaction

懂得“事务”（transaction）与“对话”（dialog）的区别是非常重要的。事务发生在一个用

户代理客户端与另一个用户代理服务端之间，包含从第一请求到最后一个响应的所有消息。

中间的阶段性的响应消息能够是以1开头的三位数字码（比如180Ringing）,最终的响应

消息则是以2开头的三位数字码（比如200OK）o事务包含的范围由SIP消息中VIA头形

成'堆栈”来决定。因此，用户代理在初始化invite后才不需要依靠DNS或者位置表进行消

息路由。

对话(Dialog)通常是从INVITE事务开始，由BYE事务结束。一个对话由CALL-ID

头唯一标识。TOtag,FROMtag与CALL—ID的结合来完整的定义。

按照rfc3665的描述，有11个基本的会话建立流程。其列出的并不一定是完整的，但

是覆盖了最好的例子。前两个流程在这一章节中进行了阐述一“成功建立会话Successful

SessionEstablishment”与“通过两个代理建立.会话SessionEstablishmentThroughTwo

Proxies”。其中的一些流程的描述你将在其他阐述呼叫前传(callforwarding)(譬如：“不接

听导致没能成功建立UnsuccessfulwithnoAnswer”与"忙音导致建立失败Unsuccessful

Busy”)的章节中看到。

RTP协议(TheRTPProtocol)

译者注：应为RealTimeTransportProtocol

实时传输协议是负责诸如音频与视频等数据的实时传输的。它标准化于RFC3550。使

用UDP协议进行传输承载。为了能够被实时传输，音频或者视频务必通过一定的编码打包。

最基本的，该协议同意使用如下的一些特性对进出的数据包的媒体传输的时间与内容要求进

行指定：

•序号

•时间戳

・无重传机制的包的前转

•源识别

•内容识别

•同步

与RTP相伴的协议叫做RTCP(RealTimeControlProtocol),被用作对RTP包进行

监控。它能够度量延迟与抖动。

编码(Codecs)

RTP协议描述的内容通常会由一种编码方式进行编码。没一种编码方式都有一种指定

的用途。一些有压缩算法而另外一些则不需要。比较普遍的是使用不需要压缩的G.711编码

方式。一个信道64Kbps的带宽要求需要一个高速的网络，通常在局域网(LANs)中比较

常见。但是在广域网(WAN)中关于一个单独的声音信道来说，64Kbps的带宽购买起来比

较昂贵。这时候诸如G,729与GSM等能够将声音包压缩至8Kbps的编码方法则能够节约

很多的带宽。由GlobalIPsound公司发明的iLBC编码方式则能够掩盖网络中由丢包造成

的影响。在丢包率带到7%的情况下，使用iLBC仍然能够维持一个比较好的声音质量。因

此关于你的VoIP提供商支持的编码方式你务必进行明智的选择。

DTMF-Relay

在一些情况下，RTP协议被用来承载诸如DTMF的信号信息。RFC2833中描述了一种

方法，这种方法就是将DTMF作为RTP协议中的命名事件(namedevents)进行传输。在

用户代理客户端与用户代理服务端之间使用同一种方法进行DTMF传输是非常重要的，

实时操纵协议(RealTimeControlProtocol-RTCP)

RTCP能够对同意的质量进行反馈。它为RTP媒体流提供带外操纵信息。诸如抖动

(Jitter),往返时延(RTT-RoundTripTime),传输延迟(latency)与丢包等的数据能够

使用RTCP进行搜集。RTCP通常用来对声音质量进行报告。

会话描述协议(SessionDescriptionProtocol-SDP)

SDP协议在RFC4566中被进行了全面的描述。它是在用户代理之间进行会话参数协

商之用的。媒体的细节，传输的地址还有其他与媒体有关的一些信息都使用SDP协议在用

户代理之间进行交互。通常，INVTIE消息中包含了SDP“供给消息”，而200Ok则包含了“回

答消息”。这些消息会在下面的图中进行展示。在下图中，你能够观察到GSM编码方式被“供

给”，但是另外一台话机却并不支持该编码，那么然后它将使用它本身支持的编码方式进行

“回答”，在这个例子中它支持的是G.711ulaw(PCMU)与G.729编码方式。会话的

“rtpmap:101”就是在RFC2833中描述的DTMF—relay信息。

INVITE(SDPOffer)

-'Sessloft■Initiatidh'Protocbl-------------------------------------------------

♦Request-Line:INVITEsip:8520©6:42989SIP/2.0

£MessageHeader

SMessagebody

sSessionDescriptionProtocol

sessionDescriptionprotocolversion(v):0

oOwner/Creator,Sessionid(o):root1096810968INIP48.8.1.4

Ownerusername:root

sessionID：10968

sessionversion:10968

OwnerNetworkType:IN

OwnerAddressType:IP4

OwnerAddress:8.8.1.4

SessionName(s):session

Connectioninformation(c):INIP48.8.1.4

TimeDescription,activerime(t):00

MediaDescription,nameandaddress(m):audio17412RTP/AVP0318101

MediaAttribute(a):rtpmap:0PCMU/8000

MediaAttribute(a):rtpmap:3GSM/8000

MediaAttribute(a):rtpmap:18G729/8000

MediaAttribute(a):fmtp:18annexb«no

MediaAttribute(a):rxpmap:101telephone-event/8000

MediaAttribute(a):fmtp:1010-16

MediaAttribute(a):silencesupp:off---------

200OK(SDPAnswer)

-SessioninitiationProtocol

田Status-Line:SIP/2.0200OK

国MessageHeader

BMessagebody

ssessionDescriptionProtocol

sessionDescriptionProtocolversion(v):0

日owner/creator,sessionid(o):root1121811218INIP4

Ownerusername:root

sessionID：11218

sessionversion:11218

OwnerNetworkType:IN

OwnerAddressType:IP4

OwnerAddress:

sessionName(s):session

土connectioninformation(c):INIP4

£TimeDescription,activetime(t):00

fMediaDescription,nameandaddress(m):audio17428RTP/AVP018101

38MediaAttribute(a):rtpmap:0PCMU/8000

iMediaAttribute(a):rtpmap:18G729/8000

♦：MediaAttribute(a):fmtp:18annexb«no

■MediaAttribute(a):rtpmap:101telephone-event/8000

tMediaAttribute(a):fmtp:1010-16

tMediaAttribute(a):silence5upp:off---------

SIP协议与OSI七层模型(TheSIPProtocol

andtheOSIModel)

懂得声音有关协议的每一个协议关于OSI模型是属于哪一层也是相当重要的。

ApplicationSER/OpenSER

PresentationG.729/G711/GSM/Speex

SessionH323/SIP/MGCP/IAX|

TransportUDP/RTP/SRTP/RTcH

NetworkIP

DatalinkFrame-Relay/ATM/PPP/Ethernet

PhysicalEthemet/V.35/RS-232/xDSL

VoIP服务提供商的整体框图(TheVoIP

Provider"BigPicture77)

UsinganATAFirewall

orSoftphone

在我们开始深入的挖掘SIP代理之前，熟悉VoIP提供商的解决方案中的所有部件是非

常重要的。服务提供者通常由多个服务器（servers）与多个服务（services）构成。这里说

的服务能够根据规模的大小来决定是被安装在一台单独的服务器上还是安装在多台机器上

面。

本书将在前几个章节中按照这张图从左到右来描述每一个部件。所有的章节中都将使用

这张图来帮助你来熟悉你所处的位置何在。

SIP代理（SIPProxy）

SIP代理是我们解决方案中的核心部件。用来负责用户的注册与保护位置数据库（映射

IP与SIP地址）。所有的SIP路由与消息都会被SIP代理处理，它也负责一些用户端级别的

服务譬如呼叫前转，白/黑名单，快速拨号等。这个部件从不处理媒体（RTP包），所有与媒

体有关的包都从用户代理客户端，服