sip编程开发基础知识入门基础

最近在学习SIP协议的相关知识，于是上网搜集了部分内容，主要包括SIP协议的概要介绍，SIP所

涉及到得相关协议，SIP开源软件介绍，SIP基础编程范例。

SIP协议全方位概要介绍

转载自：出处：中国电信

摘要：SIP协议是NGN中的重要协议，越来越得到业界的重视。本文通过SIP协议的背景、功能、

网络元素、实现机制、以及SIP消息的组成等几个方面对SIP协议做了全方位的概要性介绍，以使

读者对SIP有初步的概念和认识。

一、SIP协议的背景和功能

SIP（会话初始协议）的开发目的是用来帮助提供跨越因特网的高级电话业务。因特网电话（IP

电话）正在向一种正式的商业电话模式演进，SIP就是用来确保这种演进实现而需要的NGN（下一

代网络）系列协议中重要的一员。

SIP是IETF标准进程的一部分，它是在诸如SMTP（简单邮件传送协议）和HTTP（超文本传送

协议）基础之上建立起来的。它用来建立，改变和终止基于IP网络的用户间的呼叫。为了提供电话

业务它还需要结合不同的标准和协议：特别是需要确保传输（RTP）,与当前电话网络的信令互连，

能够确保语音质量（RSVP）,能够提供目录（LDAP）,能够鉴权用户（RADIUS）等等。

SIP被描述为用来生成，修改和终结一个或多个参与者之间的会话。这些会话包括因特网多媒体

会议，因特网（或任何IP网络）电话呼叫和多媒体发布。会话中的成员能够通过多播或单播联系的

网络来通信。SIP支持会话描述，它允许参与者在一组兼容媒体类型上达成一致。它同时通过代理和

重定向请求到用户当前位置来支持用户移动性。SIP不与任何特定的会议控制协议捆绑。

本质上，SIP提供以下功能：

名字翻译和用户定位：无论被呼叫方在哪里都确保呼叫达到被叫方。执行任何描述信息到定位信

息的映射。确保呼叫（会话）的本质细节被支持。

特征协商：它允许与呼叫有关的组（这可以是多方呼叫）在支持的特征上达成一致（注意：不是

所有方都能够支持相同级别的特征）。例如视频可以或不可以被支持。总之，存在很多需要协商的范

围。

呼叫参与者管理：呼叫中参与者能够引入其它用户加入呼叫或取消到其它用户的连接。此外，用

户可以被转移或置为呼叫保持。

呼叫特征改变：用户应该能够改变呼叫过程中的呼叫特征。例如，一呼叫可以被设置为

''voice-only",但是在呼叫过程中，用户可以需要开启视频功能。也就是说一个加入呼叫的第三方为

了加入该呼叫可以开启不同的特征。

二、SIP网络元素

SIP中有两个要素。SIP用户代理和SIP网络服务器。用户代理是呼叫的终端系统元素，而SIP

服务器是处理与多个呼叫相关联信令的网络设备。

用户代理本身具有一客户机元素（用户代理客户机UAC）和一服务器元素（用户代理服务器UAS）。

客户机元素初始呼叫而服务器元素应答呼叫。这允许点到点的呼叫通过客户机-服务器协议来完成。

SIP服务器元素提供多种类型的服务器。有三种服务器形式存在于网络中--SIP有状态代理服务

器，SIP无状态代理服务器和SIP重定向服务器。由于呼叫者未必知道被呼叫方的IP地址或主机名，

SIP服务器的主要功能是提供名字解析和用户定位。可以获得的是email形式的地址或与被呼叫方关

联的电话号码。使用该信息，呼叫者的用户代理能够确定特定服务器来解析地址信息--这可能涉及网

络中很多服务器。

SIP代理服务器接收请求，决定将这些请求传送到何处，并且将它们传送到下一服务器（使用下

一跳路由原理）。在网络中可以有多跳。

有状态和无状态代理服务器的区别是有状态代理服务器记住它接收的入请求，以及回送的响应和

它转送的出请求。无状态代理服务器一旦转送请求后就忘记所有的信息。这允许有状态代理服务器生

成请求以并行地尝试多个可能的用户位置并且送回最好的响应。无状态代理服务器可能是最快的，并

且是SIP结构的骨干。有状态代理服务器可能是离用户代理最近的本地设备，它控制用户域并且是应

用服务的主要平台。

重定向服务器接收请求，但不是将这些请求传递给下一服务器而是向呼叫者发送响应以指示被呼

叫用户的地址。这使得呼叫者可以直接联系在下一服务器上被呼叫方的地址。

三、SIP协议的实现机制

SIP是一个分层结构的协议，这意味着它的行为根据一组平等独立的处理阶段来描述，每一阶段

之间只是松耦合。协议分层描述是为了表达，从而允许功能的描述可在一个部分跨越几个元素。它不

指定任何方式的实现。当我们说某元素包含某层，我们是指它顺从该层定义的规则集。

不是协议规定的每个元素都包含各层。而且，由SIP规定的元素是逻辑元素，不是物理元素。一

个物理实现可以选择作为不同的逻辑元素，甚至可能在一个个事务的基础上。

SIP的最底层是语法和编码。它的编码使用增强Backus-Nayr形式语法（BNF）来规定。

第二层是传输层。它定义了网络上一个客户机如何发送请求和接收响应以及一个服务器如何接收

请求和发送响应。所有的SIP元素包含传输层。

第三层是事务层。事务是SIP的基本元素。一个事务是由客户机事务发送给服务器事务的请求（使

用传输层），以及对应该请求的从服务器事务发送回客户机的所有响应组成。事务层处理应用层重传,

匹配响应到请求，以及应用层超时。任何用户代理客户机（UAC）完成的任务使用一组事务产生。用

户代理包含一个事务层，有状态的代理也有。无状态的代理不包含事务层。事务层具有客户机组成部

分（称为客户机事务）和服务器组成部分（称为服务器事务），每个代表有限的状态机，它被构造来

处理特定的请求。

事务层之上的层称为事务用户（TU）o每个SIP实体，除了无状态代理，都是事务用户。当一个

TU希望发送请求，它生成一个客户机事务实例并且向它传递请求和IP地址，端口，和用来发送请求

的传输机制。一个TU生成客户机事务也能够删除它。当客户机取消一个事务时，它请求服务器停止

进一步的处理，将状态恢复到事务初始化之前，并且生成特定的错误响应到该事务。这由CANCEL

请求完成，它构成自己的事务，但涉及要取消的事务。

SIP通过EMAIL形式的地址来标明用户地址。每一用户通过一等级化的URL来标识，它通过诸

如用户电话号码或主机名等元素来构造（例如：SIP:）。因为它与EMAIL地址

的相似性，SIPURLs容易于用户的EMAIL地址关联。

SIP提供它自己的可靠性机制从而独立于分组层，并且只需不可靠的数据包服务即可。SIP可典

型地用于UDP或TCP之上。

SIP提供必要的协议机制以保证终端系统和代理服务器提供以下业务：

•用户定位

•用户能力

•用户可用性

•呼叫建立

•呼叫处理

・呼叫前转，包括：（1）等效800类型的呼叫，（2）无应答呼叫前转，（3）遇忙呼叫前转，

（4）无条件呼叫前转

・呼叫号码传递，该号码可以是任何命名机制。

•个人移动性，例如通过一个单一的、位置无关的地址来到达被呼叫方，即使被呼叫方改变了终

端。

•终端类型的协商和选择：呼叫者可以给出选择如何到达对方，例如通过因特网电话，移动电话

或应答业务等。

•终端能力协商

•呼叫者和被呼叫者鉴权

•不知情和指导式的呼叫转移

•多播会议的邀请

当一用户希望呼叫另一用户，呼叫者用INVITE请求初始呼叫，请求包含足够的信息用以被呼叫

方参与会话。如果客户机知道另一方的位置它能够直接将请求发送到另一方的IP地址。如果不知道,

客户机将请求发送到本地配置的SIP网络服务器。如果服务器是代理服务器它将解析被呼叫用户的位

置并且将请求发送给它们。有很多方法完成上步，例如搜索DNS或访问数据库。服务器也可以是重

定向服务器，它可以返回被呼叫用户的位置到呼叫客户机用以它直接与用户联系。在定位用户的过程

中，SIP网络服务器当然能够代理或重定向呼叫到其它的服务器，直到到达一个明确地知道被呼叫用

户IP地址的服务器。

一旦发现用户地址，请求就发送给该用户，此时将产生几种选择。在最简单的情况，用户电话客

户机接收请求一一也就是，用户的电话振铃。如果用户接受呼叫，客户机用客户机软件的指定能力响

应请求并且建立连接。如果用户拒绝呼叫，会话将被重定向到语音邮箱服务器或另一用户。''指定能

力''参照用户想启用的功能。例如，客户机软件可以支持视频会议，但用户只想使用音频会议，那则

只会启用音频功能。

SIP还具有另外两个有重要意义的特征。第一个是有状态SIP代理服务器具有分割入呼叫或复制

入呼叫的能力，从而可以同时运行几个扩展分支。第一个应答的分支接受呼叫。该特征在用户工作在

两位置之间（例如实验室和办公室）或者同时对经理和其秘书振铃时是非常便利的。

第二个特征是SIP独特的返回不同媒体类型的能力。举个用户联系公司的例子。当SIP服务器接

收到客户机的连接请求，它能够通过WEB交互式语音响应页面来返回到顾客的客户机，该页面具有

可获得的部门分支或提供在列表上的用户。点击适当的链接后将发送一请求到所点击选择的用户从而

建立起呼叫。

四、SIP消息的组成

有两种类型的SIP消息：

•请求：从客户机发到服务器

•响应：从服务器发到客户机

SIP请求消息包含三个元素：请求行、头、消息体。

SIP响应消息包含三个元素：状态行、头、消息体。

请求行和头域根据业务、地址和协议特征定义了呼叫的本质，消息体独立于SIP协议并且可包含

任何内容。

SIP定义了下述方法：

INVITE一一邀请用户加入呼叫。

BYE一一终止一呼叫上的两个用户之间的呼叫。

OPTIONS——请求关于服务器能力的信息。

ACK一一确认客户机已经接收到对INVITE的最终响应。

REGISTER——提供地址解析的映射，让服务器知道其它用户的位置。

INFO一一用于会话中信令。

五、结束语

SIP协议凭借其简单、易于扩展、便于实现等诸多优点越来越得到业界的青睐,它正逐步成为NGN

(下一代网络)和3G多媒体子系统域中的重要协议，并且市场上出现越来越多的支持SIP的客户端

软件和智能多媒体终端，以及用SIP协议实现的服务器和软交换设备。虽然SIP协议目前还不成熟,

但可以预见SIP必定是将来网络多媒体通信中的明星。

SIP开源软件介绍

要在windows或者linux平台下开发基于SIP的软电话，需要以下软件

服务器端软件：注册多个客户端到服务器上，可以进行通话测试

SIP客户端软件：主要用于测试，可以对别人已经完成的客户端进行抓包，以比对自己程序的发包

数据

SIP协议栈：基于某个现成的SIP协议栈来开发会加快开发进度

RTP栈：传输语言或者视频数据的协议栈

抓包测试工具：调试网络程序最有效的办法

以下介绍这些软件主要以开源软件为主

-服务器端软件

1.Asterisk：Linux系统下开源的IPPBX,功能强大稳定，主要用c语言开发。配置稍麻烦。

/

2.Vocal：Linux系统下开源的SIP服务器端。可以作为IPPBX也可以作为运营系统。很多voip

虚拟运营商都用这个作为自己的运营系统。提供BS结构的管理界面。/

3.YATE：跨平台(Linux,Windows)的开源SIP服务器端。在windows下安装非常简单。其

他方面没有进行过测试。http://yate.null.ro/pmwiki/

4.SER：Linux平台下重量级的SIP服务器断。功能比较丰富，也是很多voip虚拟运营商的系统

选择。不过据说配置比较麻烦，具体没有试过。/ser/

5.sipX：Linux平台下的SIP服务器。这个好像不能作为客户端再次注册到其他SIP服务器上。

提供BS结构的管理界面。

二SIP客户端软件

1.WindowsMessenger5.1：微软出的SIP客户端，操作方便。

2.YATEClient：跨平台(Linux,Windows)的开源SIP客户端软件。安装方便，功能简单。

http://yate.null.ro/pmwiki/

3.xten：windows平台下的SIP软电话。功能齐全，使用方便。/

三SIP协议栈

1.osip：跨平台的开源SIP协议栈。用c语言实现，体积小。http:〃/software/osip/

2.exosip：对osip进行封装，使其方便SIP客户端软件开发。同样开源跨平台。

/projects/exosip/

3.sipXtackLib：由SIPfoundry提供的开源跨平台的SIP协议栈，功能齐全。C++开发，已经被

用于开发数个商业SIP终端。

四RTP栈

1.JRTPLIB:开源的跨平台rtp栈，用C++语言开发，使用方便。

http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib

五抓包测试工具

1.Wireshark：非常有名的开源跨平台网络抓包工具，以前叫做Ethereal。

/

几种开源SIP协议栈对比

随着VoIP和NGN技术的发展，H.323时代即将过渡到SIP时代，在H.323的开源协议栈中,

Openh323占统治地位，它把一个复杂而又先进的H.323协议栈展现在普通程序员的眼前，为

H.323普及立下了汗马功劳。而然当在SIP时代，则出现了群雄割据的状况，SIP相对于H.323

简单，灵活，于是各种协议栈层出不穷，下面将详细对比最具有代表性的5个开源项目：

OPAL,VOCAL,sipX,ReSIProcate,oSIP

OPAL是OpenPhoneAbstractionLibrary,是Openh323的下一个版本，它仍然使用了

Openh323的体系结构，并在其基础上进行扩展，同时实现了SIP,H.323,但在音频和视频的编码

和传输部分有较大改动。OPAL初衷设计是包含任何电话通信协议，所以其底层进行了高度的抽象化,

所以也能够很容易的支持MGCP,PSTN和将来会出现的协议。不过由于Openh323的最后一个版

本还在开发中，所以原本6月发布的OPAL也被推迟，现有的OPAL还非常不完善，BUG也非常多，

不过相信以Openh323的开发班底，一定能让OPAL十分优秀。

CVS::pserver:anonymous@:/cvsroot/openh323/opal

Language:C++

VxWorksport:Yes

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:No

SupportsRFC3515:Yes

SupportsRFC3262:No

SupportsRFC3311:No

TCP:Yes

UDP:Yes

SIZE:8MB

License:MPL

Document:None

Samples:UA,GK

VOCAL是开发的SIP系统，VOCAL应该是目前功能最完善，使用者最多的开源

SIP协议栈了.它不只包括了协议栈，还包括了h323与sip转换网关，对SIP的各种Serve「的功

能支持也非常完善,不过很可惜，不支持windows平台，而且自从vovida被CISCO收购以后就停

止了开发，最后的版本是2003年4月的L5.0。

CVS::pserver:anonymous@:/cvsroot/vocal

Language:C++

VxWorksport:No

Win32port:Partial

Linuxport:Yes

SupportsRFC3261:Partial

SupportsRFC2327:Yes

SupportsRFC3264:

SupportsRFC3263:

SupportsRFC3515:Yes

SupportsRFC3262:

SupportsRFC3311:

TCP:Yes

UDP:Yes

SIZE:6MB

License:Vovidasoftwarelicencse

Document:Few

Samples:UA,GK,GW

sipX是一个SIP系统，由SIPFoundry开发。sipX是从reSIProcate分离出来的，sipX除了

包括SIPstack外，还包括了sipXphone,sipXproxy,sipXregistry等等…，由它们构成了完整的

SIP系统，而且sipx还支持嵌入式系统，各个模块可以按需取舍。不过可惜是几乎没有任何开发文

档。

SVN:/viewsvn/

Language:C++

VxWorksport:Yes

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:Yes

SupportsRFC3515:Yes

SupportsRFC3262:No

SupportsRFC3311:No

TCP:Yes

UDP:Yes

SIZE:<4Mb

License:LGPL

Document:None

Samples:UA,GK,GW

ReSIProcate同样也是由SIPFoundry开发，ReSIProcate最开始起源于Vocal,由于Vocal

开始只支持rfc3254,为了支持最新的rfc3261,ReSIProcate诞生了，但现在，ReSIProcate已

经成为一个独立SIP协议栈了，它十分稳定，并且很多商业程序都在使用。

SVN:/viewsvn/resiprocate/main/sip/

Language:C++

VxWorksport:No

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:Partial

SupportsRFC3515:Yes

SupportsRFC3262:No

SupportsRFC3311:No

TCP:Yes

UDP:Yes

SIZE:<2.5Mb

License:Vovida

Document:Few

Samples:None

OSIP的开发开始于2000年7月，第一个版本在2001年5月发布，到现在已经发展到2.0.9

了。它采用ANSIC编写，而且结构简单小巧，所以速度特别快，它并不提供高层的SIP会话控制

API,它主要提供一些解析SIP/SDP消息的API和事务处理的状态机，oSIP的作者还开发了基于

oSIP的UAlib:exosip和proxyserverlib:partysip.

CVS::ext:anoncvs@:/cvsroot/osip

Language:C

VxWorksport:Yes

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:Yes

SupportsRFC3515:No

SupportsRFC3262:No

SupportsRFC3311:Yes

TCP:Yes

UDP:Yes

SIZE:400kb

License:LGPL

Samples:UA,GK

综合上述评测，可以看出5种SIP协议栈各有千秋，OPAL有发展潜力，VOCAL比较完善，sipX

兼容性好，ReSIProcdte教稳定，oSIP小巧而快速。所以要根据应用的不同选择恰当的协议栈进行

研究开发要在windows或者linux平台下开发基于SIP的软电话，需要以下软件

服务器端软件：注册多个客户端到服务器上，可以进行通话测试

SIP客户端软件：主要用于测试，可以对别人已经完成的客户端进行抓包，以比对自己程序的发包

数据

SIP协议栈：基于某个现成的SIP协议栈来开发会加快开发进度

RTP栈：传输语言或者视频数据的协议栈

抓包测试工具：调试网络程序最有效的办法

以下介绍这些软件主要以开源软件为主

-服务器端软件

1.Asterisk：Linux系统下开源的IPPBX,功能强大稳定，主要用c语言开发。配置稍麻烦。

/

2.Vocal：Linux系统下开源的SIP服务器端。可以作为IPPBX也可以作为运营系统。很多voip

虚拟运营商都用这个作为自己的运营系统。提供BS结构的管理界面。/

3.YATE：跨平台(Linux,Windows)的开源SIP服务器端。在windows下安装非常简单。其

他方面没有进行过测试。http://yate.null.ro/pmwiki/

4.SER：Linux平台下重量级的SIP服务器断。功能比较丰富，也是很多voip虚拟运营商的系统

选择。不过据说配置比较麻烦，具体没有试过。/ser/

5.sipX：Linux平台下的SIP服务器。这个好像不能作为客户端再次注册到其他SIP服务器上。

提供BS结构的管理界面。

二SIP客户端软件

1.WindowsMessenger5.1：微软出的SIP客户端，操作方便。

2.YATEClient：跨平台(Linux,Windows)的开源SIP客户端软件。安装方便，功能简单。

http://yate.null.ro/pmwiki/

3.xten：windows平台下的SIP软电话。功能齐全，使用方便。/

三SIP协议栈

1.osip：跨平台的开源SIP协议栈。用c语言实现，体积小。http:〃/software/osip/

2.exosip：对osip进行封装，使其方便SIP客户端软件开发。同样开源跨平台。

/projects/exosip/

3.sipXtackLib：由SIPfoundry提供的开源跨平台的SIP协议栈，功能齐全。C++开发，已经被

用于开发数个商业SIP终端。

四RTP栈

1.JRTPLIB:开源的跨平台rtp栈，用C++语言开发，使用方便。

http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib

五抓包测试工具

1.Wireshark：非常有名的开源跨平台网络抓包工具，以前叫做Ethereal。

/

几种开源SIP协议栈对比

随着VoIP和NGN技术的发展，H.323时代即将过渡到SIP时代，在H.323的开源协议栈中,

Openh323占统治地位，它把一个复杂而又先进的H.323协议栈展现在普通程序员的眼前，为

H.323普及立下了汗马功劳。而然当在SIP时代，则出现了群雄割据的状况，SIP相对于H.323

简单，灵活，于是各种协议栈层出不穷，下面将详细对比最具有代表性的5个开源项目：

OPAL,VOCAL,sipX,ReSIProcate,oSIP

OPAL是OpenPhoneAbstractionLibrary,是Openh323的下一个版本，它仍然使用了

Openh323的体系结构，并在其基础上进行扩展，同时实现了SIP,H.323,但在音频和视频的编码

和传输部分有较大改动。OPAL初衷设计是包含任何电话通信协议，所以其底层进行了高度的抽象化,

所以也能够很容易的支持MGCP,PSTN和将来会出现的协议。不过由于Openh323的最后一个版

本还在开发中，所以原本6月发布的OPAL也被推迟，现有的OPAL还非常不完善，BUG也非常多，

不过相信以Openh323的开发班底，一定能让OPAL十分优秀。

CVS::pserver:anonymous@:/cvsroot/openh323/opal

Language:C++

VxWorksport:Yes

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:No

SupportsRFC3515:Yes

SupportsRFC3262:No

SupportsRFC3311:No

TCP:Yes

UDP:Yes

SIZE:8MB

License:MPL

Document:None

Samples:UA,GK

VOCAL是开发的SIP系统，VOCAL应该是目前功能最完善，使用者最多的开源

SIP协议栈了.它不只包括了协议栈，还包括了h323与sip转换网关，对SIP的各种Serve「的功

能支持也非常完善,不过很可惜，不支持windows平台，而且自从vovida被CISCO收购以后就停

止了开发，最后的版本是2003年4月的L5.0。

CVS::pserver:anonymous@:/cvsroot/vocal

Language:C++

VxWorksport:No

Win32port:Partial

Linuxport:Yes

SupportsRFC3261:Partial

SupportsRFC2327:Yes

SupportsRFC3264:

SupportsRFC3263:

SupportsRFC3515:Yes

SupportsRFC3262:

SupportsRFC3311:

TCP:Yes

UDP:Yes

SIZE:6MB

License:Vovidasoftwarelicencse

Document:Few

Samples:UA,GKZGW

sipX是一个SIP系统，由SIPFoundry开发。sipX是从reSIP「ocdte分离出来的，sipX除了

包括SIPstack外，还包括了sipXphone,sipXproxy,sipXregistry等等由它们构成了完整的

SIP系统，而且sipx还支持嵌入式系统，各个模块可以按需取舍。不过可惜是几乎没有任何开发文

档。

SVN:/viewsvn/

Language:C++

VxWorksport:Yes

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:Yes

SupportsRFC3515:Yes

SupportsRFC3262:No

SupportsRFC3311:No

TCP:Yes

UDP:Yes

SIZE:<4Mb

License:LGPL

Document:None

Samples:UA,GK,GW

ReSIProcate同样也是由SIPFoundry开发，ReSIProcate最开始起源于Vocal,由于Vocal

开始只支持rfc3254,为了支持最新的rfc3261,ReSIProcate诞生了，但现在，ReSIProcate已

经成为一个独立SIP协议栈了，它十分稳定，并且很多商业程序都在使用。

SVN:/viewsvn/resiprocate/main/sip/

Language:C++

VxWorksport:No

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:Partial

SupportsRFC3515:Yes

SupportsRFC3262:No

SupportsRFC3311:No

TCP:Yes

UDP:Yes

SIZE:<2.5Mb

License:Vovida

Document:Few

Samples:None

OSIP的开发开始于2000年7月，第一个版本在2001年5月发布，到现在已经发展到2.0.9

了。它采用ANSIC编写，而且结构简单小巧，所以速度特别快，它并不提供高层的SIP会话控制

API,它主要提供一些解析SIP/SDP消息的API和事务处理的状态机，OSIP的作者还开发了基于

oSIP的UAlib:exosip和proxyserverlib:partysip.

CVS::ext:anoncvs@:/cvsroot/osip

Language:C

VxWorksport:Yes

Win32port:Yes

Linuxport:Yes

SupportsRFC3261:Yes

SupportsRFC2327:Yes

SupportsRFC3264:Yes

SupportsRFC3263:Yes

SupportsRFC3515:No

SupportsRFC3262:No

SupportsRFC3311:Yes

TCP:Yes

UDP:Yes

SIZE:400kb

License:LGPL

Samples:UA,GK

综合上述评测，可以看出5种SIP协议栈各有千秋，OPAL有发展潜力，VOCAL比较完善，sipX

兼容性好，ReSIProcate教稳定，oSIP小巧而快速。所以要根据应用的不同选择恰当的协议栈进行

研究开发。。

SIP所涉及到得相关协议

SIP标准

1.RFC3261:SessionInitiationProtocol

2RFC3262:ReliabilityofProvisionalResponsesinSIP

3R.FC3263:SIP:LocatingSIPServers

4RFC3264:AnOfferAnswerModelwithSessionDescription

5RFC3265:SIP-SpecificEventNotification

6RFC3311:TheSIPUPDATEMethod

7.RFC3312:IntegrationofResourceManagementandSIP

8RFC3313:PrivateSessionInitiationProtocol(SIP)ExtensionsforMedia

Authorization

9.RFC3323:APrivacymechanismfortheSessionInitiationProtocol

10.RFC3325:PrivateExtensionstotheSessionInitiationProtocol(SIP)for

AssertedIdentitywithTrustedNetworks

11.RFC3326:TheReasonHeaderfortheSessionInitiationProtocol

12.RFC3327:SessionInitiationProtocol(SIP)ExtensionHeaderFieldfor

RegisteringNon-AdjacentContacts

13.RFC3329:SecurityMechanismAgreementfortheSIP

14.RFC3372:SIPforTelephones(SIP-T):ContextandArchitectures

15.RFC3428:SIPExtensionsforInstantMessaging

16.RFC3486:CompressingtheSessionInitiationProtocol(SIP)

17.RFC3515:TheREFERMethod

18.RFC3608:SessionInitiationProtocol(SIP)ExtensionHeaderFieldforService

RouteDiscoveryDuringRegistration

19.RFC2806:URLsforTelephoneCalls

20.RFC2848:PINT-IPAccesstoTelephoneCallServices

21.RFC2915:TheNAPTRDNSResourceRecord

22.RFC2976:TheSIPINFOMethod

23.RFC3204:MIMEmediatypesforISUPandQSIGObjects

24.draft-ieft-sipping-el64-02:UsingENUMforSIPApplication

25.draft-ieft-sipping-cc-transfer-05:CallTransfer

26.draft-ieft-sip-referredby-OO:TheReferred-ByMechansim

27.draft-ieft-sip-replaces-03:TheSIPReplacesHeader

28.draft-ietf-session-timer-10:TheSIPSessionTimer

29.draft-ietf-sipping-3gpp-r5-requirements-00:3rdGenerationPartnershipProject

(3GPP)Release5requirementsontheSessionInitiationProtocol

30.draft-ietf-sip-nat-02:AnExtensiontotheSessionInitiationProtocolfor

SysmmetricResponseRouting

31.draft-ietf-sipping-mwi-02.txt:AMessageSummaryandMessageWaiting

IndicationEventPackagefortheSessionInitiationProtocol.

32.draft-ietf-simpie-presence-10:SIPExtensionsforPresence

33.draft-ieft-simple-im-sdp-00:SIP-SDPExtensionsforSIPInstantMessage

Sessions

34.ITU-TRecommendationT.38:Proceduresforreal-timeGroup3facsimile

communicationoverIPnetworks

35.draft-yu-tel-trl-07:ExtensiontoTelURLtosupportNumberPortabiltiyand

FreephoneService

36.draft-ietf-mmusic-sdp-qos-OO:EstablishingQOSandSecurityPreconditionsfor

SDPsessions

SIP相关协议

1.RFC1006:ISOtransportservicesontopoftheTCPVersion3

2.RFC2030:SimpleNetworkTimeProtocol(SNTP)Version4forIPv4,IPv6and

OSI

3.RFC2246:TheTLSProtocolVersion1.0

4.RFC2327:SDPSessionDescriptionProtocol

5.RFC3024:MIMEmediatypesofISUPandQSIGObjects

SIP学习入门范例（1）

学习SIP协议最快捷的方法是通过范例来学习，因此我从UnderstandSIP上找了4个最简单呼

叫过程来分析。通过对这些流程图以及每个呼叫所包含的消息体文本分析，尽快熟悉SIP呼叫原理。

PS.如果有什么地方说明不妥，请告诉我

一、基本SIP会话建立范例

下面的流程图显示出最简单的SIP呼叫流程。它由两个呼叫终端组成（其实真正的系统并没有这么

简单），呼叫终端可以为SIP电话机或者具备SIP功能的手机等终端设备。在这里我们假设它是

能够连接到IP网的终端设备，并且它们已经知道对方的IP地址。

PS.因为这是第一节，每个字段我们讲得会比较详细，后面章节如何字段意义差不多，我们将会省略。

对于某些常用的，有重要意义的字段，我们还将在专门的地方说明。

INVITE

主叫方Tesla首先发起INVITE消息到被叫方Marconi。INVITE消息包含会话类型和一些呼叫所

必须的参数。会话类型可能是单纯的语音，也可能是网络会议所用的多媒体视频，还可能是游戏会话。

下面是消息体范例，我们来详细分析各个字段的意义：

INVITEsip:marconi@SIP/2.0

<=请求方法、请求地址（Request—URI）、SIP版本号（目前都是SIP/2.0）

<=请求地址一般就是被叫方地址，跟MSN中好友eMail地址类似

Via:SIP/2.0/UDP:5060;branch=z9hG4bKfwl9b

<=SIP版本号（2.0）、传输类型（UDP）、呼叫地址、

v=branch是一随机码，它被看作传输标识

<=Via字段中地址是消息发送方或代理转发方设备地址，一般由主机地址和端口号组成

<=传输类型可以为UDP、TCP、TLS、SCTP

Max-Forwards:70

<=最大跳跃数，就是经过SIP服务器的跳跃次数，主要是防止循环跳跃

<=每尽管一台代理服务器，该整数减一

To:G.Marconi<sip:Marconi@>

From:NikolaTesla<sip:n.tesla@>;tag=76341

<=表示请求消息的发送方和目标方

<=如果里面有用户名标签，地址要求用尖括号包起来

<=对于INVITE消息，可以在From字段中包含tag,它也是个随机码

Call-ID:123456789@

<=呼叫ID是由本地设备生成的，全局唯一值。每次呼叫该值唯一不变

<二对于用户代理发送INVITE消息，本地将生成Fromtag和Call-ID全局唯一码，被

叫方代理则生成Totag全局唯一码。这三个随机码做为整个对话中对话标识（dialogidentifier）

在通话双方使用。

CSeq:1INVITE

<=CSeq,又叫命令队列（CommandSeqence）,每发送一个新的请求，该数自动加1

*以上几个字段是所有SIP消息体所必须的，其它头字段有些是可选的，有些在特定请求也是必须

Subject:AboutThatPowerOutage...

Contact:<sip:n.tesla@>

<=Contact是INVITE消息所必须的，它用来路由到被叫设备地址，也称为用户代理（UA）

Content-Type:application/sdp

Content-Length:158

<=最后两位附属字段说明消息体类型以及字段长度

v=0v=SDP版本号，目前都是0

o=Tesla28908445262890844526INIP4v=主叫源地址，类型等

s=PhoneCallv=主题

c=INIP403v=连接

t=00v=时间戳

m=audio49170RTP/AVP0v=媒体

a=rtpmap:0PCMU/8000<=媒体属性

v=从上面SDP消息体我们可以得出下面信息

v=连接IP地址：03

v=媒体格式：audio

<=端口号：49170

<=媒体传输类型：RTP

v=媒体编码：PCMuLaw

<=采样率：8000Hz

180Ringing

当被叫方接收到INVITE请求消息后，将回复180Ringing。顾名思义，就是发回铃音，提示主叫

方电话已连接上了，正等待被叫应答。被叫方接收到INVITE消息后也会发生响铃或者其它有呼入

提示，这由被叫方设定（我们可以把它想象成我们自己设定手机铃声）。对于180响应又被称为''消

息及时响应〃，它是一种用来测试被叫状态的一种响应。因此它所包含的信息不多，具体180响应

消息如下：

SIP/2.0180Ringing

Via:SIP/2.0/UDP:5060;branch=z9hG4bKfw19b

;received=03v=这里增加一个received参数，标识接收方IP地址

To:G.Marconi<sip:marconi@>;tag=a53e42<=上已提至ij,Totag做为被叫

方标识

From:NikolaTesla<sip:n.tesla@>;tag=76341v=要求很发送方From

tag一致

Call-ID:123456789@

CSeq:1INVITE

Contact:<sip:marconi@>

Content-Length:0

v=对于180Ringing响应，基本上就是将INVITE的Via、To、From、Call-ID和CSeq

内容复制过来，对于首行标出SIP版本号，响应代码(180)和动作原因(reasonphrase)

<=注意这里From和To地址，因为它们用来指定呼叫方向，因此这里的200OK响应并没

有将地址对调，仍然保持原样。一点不同的是To头字段添加了由被叫方Marconi生成的tag标

识

200Ok

被叫响铃后，如果被叫用户Marconi接起电话，则发出200OK响应。这个响应除了做为接通指

示之外，还有一个功能是用来指定被叫允许的连接媒体格式，让主叫方确认是否可以接收该媒体。

消息体如下：

SIP/2.0200OK

Via:SIP/2.0/UDP:5060;branch=z9hG4bKfw19b

;received=03

To:G.Marconi<sip:marconi@>;tag=a53e42

From:NikolaTesla<sip:n.tesla@>;tag=76341

Call-ID:123456789@

CSeq:1INVITE

Contact:<sip:marconi@>

Content-Type:application/sdp

Content-Length:155

v=头字段部分基本同上

v=0

o=Marconi28908445282890844528INIP4

s=PhoneCall

c=INIP403

t=00

m=audio60000RTP/AVP0

a=rtpmap:0PCMU/8000

v=从上面SDP消息体我们可以得出下面信息

v=终端IP地址：03

v=媒体格式：audio

<=端口号：60000

<=媒体传输类型：RTP

v=媒体编码：PCMuLaw

<=采样率：8000Hz

ACK

通话前最后一步是主叫方确认200OK响应。该项确认证明连接被允许，即将使用另一种协议开始

媒体连接。这另一种协议是上面在SDP消息段中所协商好的RTP格式。该ACK响应内容如下：

ACKsip:marconi@SIP/2.0

Via:SIP/2.0/UDP:5060;branch=z9hG4bK321g

Max-Forwards:70

To:G.Marconi<sip:marconi@>;tag=a53e42

From:NikolaTesla<sip:n.tesla@>;tag=76341

Call-ID:123456789@

CSeq:1ACK

Content-Length:0

BYE

通话完毕后，由被叫方Marconi首先挂机，发送BYE请求命令。注意这回由Marconi做为主叫

方了，因此Via字段和From、To与INVITE字段有所不同。其实也就是倒置。

BYEsip:n.tesla@SIP/2.0

Via:SIP/2.0/UDP:5060;branch=z9hG4bK392kf

Max-Forwards:70

To:NikolaTesla<sip:n.tesla@>;tag=76341

From:G.Marconi<sip:marconi@>;tag=a53e42

Call-ID:123456789@

CSeq:1BYE

Content-Length:0

200OK

BYE之后，要求被叫方发200Ok确认，也就是让主叫知道被叫已经知道你挂断了。（注意这里所

说的主被叫角色已经倒过来了）打个比方，通话之后，有一方要求挂机，另一方需要知道它已经挂机

了。

SIP/2.0200OK

Via:SIP/2.0/UDP:5060;branch=z9hG4bK392kf

;received=03

To:NikolaTesla<sip:n.tesla@>;tag=76341

From:G.Marconi<sip:marconi@>;tag=a53e42

Call-ID:123456789@

CSeq:1BYE

Content-Length:0

到此，我们已经将最简单的呼叫过程讲完了。该过程简单在于两个终端之间没有其它设备，完全的点

对点连接，它们之间只需要知道对方IP地址即可。现实生活中这种呼叫形式是很少见的。后面我们

将继续介绍另一种利用代理方式进行呼叫连接。

留个疑问：为什么说这种点对点的方式比较少用？

TeslaMarconi

_INVITE

~>

180Ringing

4二

200OK

-4

ACK

►

«Mediasession.

BYE一

◄-

200OK

SIP学习入门范例(2)

二、通过代理服务器的SIP呼叫

在前面一个例子中，我们事先假设两个终端知道对方IP地址。而在现实情况下，这种非常少见。因

为IP地址不像是电话号码，基本上每个人都是固定的，大多数情况，我们只知道被叫方名字，而并

不知道对方在哪，也不知道对方终端的IP地址。因此今天，我们继续介绍另一种呼叫方式，即通过

代理服务器进行呼叫。通过代理服务器进行呼叫，和我们使用HTTP代理上网大同小异。我们这个

例子，只有一个代理服务器。

PS.因为这里有很多内容和第一节相似，我们大量列举内容，只在个别地方说明

Ml：首先是主叫方Schroedinger发送Invite请求给代理服务器。

INVITEsip:werner.heisenberg@munich.deSIP/2.0

v=对于基于代理服务器的呼叫连接，代理服务器要处理2部分内容。”@“前的是用户，后面是

终端设备地址，需要DNS解析成标准IP地址。

Via:SIP/2.0/UDP03:5060;branch=z9hG4bKmpl7a

Max-Forwards:70

To:Heisenberg<sip:werner.heisenberg@munich.de>

From:E.Schroedinger<sip:schroed5244@>;tag=42

Call-ID:10@100,101.102.103

CSeq:1INVITE

Subject:Whereareyouexactly?

Contact:<sip:schroed5244@>

Content-Type:application/sdp

Content-Length:159

v=0

o=schroed524428908445262890844526INIP403

s=PhoneCall

t=00

c=INIP403

m=audio49170RTP/AVP0

a=rtpmap:0PCMU/8000

代理服务器在它的定位数据库中查找SIP地址(sip:werner.heisenberg@munich.de)。这里有

两个步骤：

1、首先UA查询DNS,确定代理服务器位置；然后由代理服务器查询定位被叫地址

2、代理服务器将Invite消息转发到被叫地址，在Invite消息中增加第二Via字段

M2：代理服务器转发INVITE消息

INVITEsip:werner.heisenberg@03SIP/2.0

Via:SIP/2.0/UDPproxy.munich.de:5060;branch=z9hG4bK83842.1

<=这里增加了个新Via,由代理服务器产生

Via:SIP/2.0/UDP03:5060;branch=z9hG4bKmpl7a

Max-Forwards:69<=经过一个跳跃，这里减1

To:Heisenberg<sip:werner.heisenberg@munich.de>

From:E.Schroedinger<sip:schroed5244@>;tag=42

Call-ID:10@100,101.102.103

CSeq:1INVITE

Contact:vsip:schroed5244@pc33,>

Content-Type:application/sdp

Content-Length:159

v=0

o=schroed524428908445262890844526INIP403

s=PhoneCall

c=INIP403

t=00

m=audio49172RTP/AVP0

a=rtpmap:0PCMU/8000

M3：被叫放回铃180Ringing

SIP/2.0180Ringing

Via:SIP/2.0/UDPproxy.munich.de:5060;branch=z9hG4bK83842.1

;received=05

Via:SIP/2.0/UDP03:5060;branch=z9hG4bKmpl7a

To:Heisenberg<sip:werner.heisenberg@munich.de>;tag=314159

From:E.Schroedinger<sip:schroed5244@>;tag=42

Call-ID:10@03

CSeq:1INVITE

Contac