博客园_木瓜脑袋

双网卡共享上网中的桥接设置[转]

2011-09-30T02:32:00Z

From: http://hi.baidu.com/man_jack/blog/item/19391f542b43bc56564e00e9.html

局域网中新增了一台客户机，但集线器端口已接满，为一台电脑增加集线器太不合算。怎么办？windows XP的“网桥”功能就派上用场了，不过需要一个前提条件，就是局域网中必须有一台安装了双网卡的Windows XP系统客户机。下面介绍具体实现方法：
为了容易区分说明对象，以下将装了双网卡的客户机称为“客户A”，新增的那台客户机称为“客户B”，具体连接和设置方法如下：
假设局域网使用的网段为192.168.0.x。
首先确保“客户A”能够访问局域网上的资源和Internet，并配置好双网卡，其中连接到集线器的网卡IP地址为192.168.0.1，连接到“客户B”网卡IP地址为192.168.0.2。打开“网络和拨号连接”，将原先连接局域网的“本地连接”重命名为“本地连接-主机”，将另一“本地连接”重名为“本地连接-客户”，然后用双绞线（双机直联的方式）将“本地连接-客户”对应的网卡和“客户B”机上的网卡直接连起来。
接下来在“客户B”机上设置网络属性，指定一空IP地址和“计算机名”，如IP地址:192.168.0.3 ,计算机名为：客户B,其他设置如“子网掩码”、“默认网关”、“D 服务器”和“客户A”机的设置相同。
现在如果“客户A”和“客户B”能够互相访问资源，那么就说明已经成功一半了，接下来需要做的就是用Windows XP的“网桥”将“本地连接-主机”和“本地连接-客户”连接起来。
在“客户A”机上进入“网络和拨号连接”窗口，选中“本地连接-客户”和“本地连接-主机”单击右键，点击右键菜单中的“网桥”命令，系统开始给这两个连接进行桥接，如果以上设置一切正确，此时桥接会成功启用。现在就会出现一个“网络桥”的图标。鼠标右键点击图标选择“属性”，在“Internet协议（TCP/IP）”属性中设置IP属性（如图）。比如：192.168.0.4。好了，现在“客户B”机也可访问局域网其它电脑和Internet了，至此实现了在局域网中双机共用一Hub端口共享上网。

本文链接

SIP协议总结[转]

2011-05-19T07:21:00Z

SIP协议是一个用于建立，更改和终止多媒体会话的应用层控制协议，大量借鉴了成熟的HTTP协议（文本格式编码，Request消息中的method等），采用基于文本的UTF-8编码方式，可以承载与UDP或者TCP协议之上(首选UDP)。和Diameter协议类似，SIP也是有一个基础协议和很多扩展协议，基础协议在RFC3261中定义，本文主要概括SIP基础协议的要点。

1. 基本概念：

· Session：Session简单的说就是一次通话，从摘机拨号开始到最终的挂机之间所有的SIP消息都属于一个Session，它们具有相同的Call-Id。

· Dialog：基于Peer-to-Peer，描述了两端的User Agents在一段时间内的关联。Dialog用Dialog Id来表示，Dialog Id是由三部分组成的：Call-Id，from中的tag，to中的tag。只有对Invite消息响应的的2xx 和 101-199 消息才能建立一个Dialog。100 Trying相应无法建立Dialog，因为100 Trying中的To属性没有tag值。

· Transaction：一个Transction是有一个Request消息和一个或者多个临时或者最终应答消息构成的。如果对Invite的应答是200 OK，则接下来的ACK消息认为是另一个transaction。

2. SIP网络实体：

· UA(User Agent)：和用户直接交互的SIP设备，可以是硬件的SIP电话也可以是电脑上具有SIP电话功能的软件等；发送SIP Request消息的UA即UAC(User Agent Client), 接受SIP Request消息的UA即UAS(User Agent Server), 一个UA通常既是UAC又是UAS。

· Proxy Server：进行消息转发，负责把消息转发给最终用户或者另一个Proxy Server。

· Redirect Server：和Diameter的Redirect Server类似，不进行消息转发，而是给消息发送方回复一个或者多个地址，建议发送方把消息发往这些地址。Redirect Server返回的地址并不一定就是最终用户的地址，也有可能是另一个Proxy Server的地址。

· Registrars: 因为SIP需要支持用户的移动性，所以当用户改变位置后需要对新位置的终端进行注册，Registrars接受SIP用户注册，从而得知可以从何处找打当前用户。Registrars通常位于SIP Server(Proxy Server 或者Redirect Server)中。

· Location Server：不是SIP实体，之所以说它不是SIP实体是因为Location Server上面不必运行SIP协议栈，SIP Server和 Location Server之间的通信方式也不是用SIP(比如用LDAP)。Location Server的作用是保存SIP用户位置数据(IP 或者Hostname)，比如当一个SIP用户向SIP Server注册之后，SIP Server将该SIP用户位置信息上传到Location Server中，当SIP Server收到需要发送给该SIP用户的消息时，SIP Server再向Location Server询问该用户位置信息(IP 或者Hostname)。

3. SIP消息分类：

SIP消息分为如下两类:

· 请求消息：UAC发给UAS的消息，包括INVITE、ACK、BYE、CANCEL、OPTION和REGISTER消息。

· 响应消息：UAS回应给UAC的消息，包括1xx、2xx、3xx、4xx、5xx、6xx响应消息，每类消息的具体含义如下表：

1xx	进展相应	临时相应
2xx	成功	最终相应
3xx	重定向错误	最终相应
4xx	客户端错误	最终相应
5xx	服务端错误	最终相应
6xx	全局错误	最终相应

4. SIP消息格式：

SIP由于是采用文本格式编码，所以消息格式很简单，是由Message Header加可选的Message body构成，Message Header 从第二行开始每一行都由“Tag :Valued”格式组成，每一行描述一个属性。头部的属性有很多，基本协议中定义了一部分，扩展协议也定义了相应的头部属性。如果消息中携带了Message body，则Message Header和Message body之间用一个空行分割开来；Message body通常有“Content-Type”和“Content-Length”属性来对Message body进行解释，例如：
Content-Type: application/sdp
Content-Length: 212

SIP消息也可以携带多个Message body，比如可以带上SDP信息和主叫方的照片，这样被叫就能看到主叫方的头像了。

SIP消息在经过Proxy的时候，Proxy只关心Message Header，而不会检查Message body，所以说Message body对Proxy是透明的。

5. SDP(Session Description Protocol)：

在SIP的Message body中最常见的就是SDP，这里概述一下SDP。Session Description Protocol (SDP) 在RFC 2327中被定义；SDP中携带了一些必要信息，以供用户可以加入一个多媒体会话，比如IP地址，端口号，会话的日期时间等；这有点儿类似电视台的节目单，有了节目单，我们就可以在指定的时间切换到指定的频道收看到预期的节目。SDP是单独定义的，和SIP没有必然的联系，SDP信息可以通过各种途径传输比如Email，Webpage等，SIP只是众多传输SDP方式中的一种而已。

1) SDP语法：

SDP也是用文本格式描述的，一个SDP Description可以包含很多行，每一行的格式如下：
Type = Value
Type只用一个字母来表示；一个SDP Description通常有一个Session-level和多个Media-level信息组成；Session-level信息用来描述整个Session，每个Media-level信息用来描述一个特定的媒体流。Session-level总以”v=0”开头，Media-level总已”m=<media type> <port number> <transport protocol> <media formats>”开头,。下面是一个SDP Description的例子，该例子中包含了三个Media-level信息：
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112
s=SIP seminar
i=A Seminar on the Session Initiation Protocol
u=http://www.cs.columbia.edu/sip
e=bob@university.edu
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

该例中o描述该session的发起者是Bob以及他的IP地址；s描述该session的名字；i描述了该session的一般信息；u说明可以从这个URL中获取和该session相关的更多信息；e描述了该session联系人的email。C和t描述了什么时间从哪里可以接收到该Session的multicast。m描述了一个媒体流的端口号，传输协议，媒体格式等信息。a可以用来对SDP进行扩展，比如双方如果协商音频的音量，可以用下面的SDP描述：
m=audio 49170 RTP/AVP 0
a=volume:8
前提是双方都需要理解volume的含义，如果对方不理解volume，也不会出错，只是将其忽略。

2) SDP描述中常见属性：

v	Protocol version
b	Bandwidth information
o	Owner of the session and session identifier
z	Time zone adjustments
s	Name of the session
k	Encryption key
i	Information about the session
a	Attribute lines
u	URL containing a description of the session
t	Time when the session is active
e	E-mail address to obtain information about the session
r	Times when the session will be repeated
p	Phone number to obtain information about the session
m	Media line
c	Connection information
i	Information about a media line

6. SIP呼叫流程实例分析：

下图是一个完整的SIP呼叫消息流示意图，这里重点关注SIP消息流，下一篇文中将给出一个稍微复杂的例子，那个例子中将重点关注SIP消息的路由和SIP常见头部字段的含义。

Laura要与Bob通话，Laura拨打Bob的的Public URI：sip:Bob.Johnson@company.com，给Bob一个Invite消息，在Invite消息中携带了SDP，表明Laura期望在UDP端口20002上收到包含PCM voice编码的RTP数据包。Proxy收到这个Invite消息后转发给Bob，同时给Laura回送一个100 Trying消息(Trying消息是Hop-to-Hop的，不会被转发)。Bob收到Invite消息后开始振铃，返回180 Ringing消息给Laura，Laura侧会听到回铃音。

INVITE sip:Bob.Johnson@company.com SIP/2.0

Via: SIP/2.0/UDP workstation1000.university.com:5060

From: Laura Brown <sip:Laura.Brown@university.com>

To: Bob Johnson sip:Bob.Johnson@company.com

Call-ID: 12345678@workstation1000.university.com

CSeq: 1 INVITE

Contact: Laura Brown <sip:Laura@workstation1000.university.com>

Content-Type: application/sdp

Content-Length: 154

v=0

o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com

s=Let us talk for a while

c=IN IP4 138.85.27.10

t=0 0

m=audio 20002 RTP/AVP 0

当Bob摘机后，一个200 OK的最终应答消息会被返回给Laura，消息中携带了一个SDP，表明Bob可以在UDP端口41000上接受数据包。Laura收到200 OK后给Bob发送一个ACK消息，确认已经收到200 OK。此时双方进入通话。

SIP/2.0 200 OK

Via: SIP/2.0/UDP 131.160.1.110

Via: SIP/2.0/UDP workstation1000.university.com:5060

From: Laura Brown <sip:Laura.Brown@university.com>

To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159

Call-ID: 12345678@workstation1000.university.com

CSeq: 1 INVITE

Contact: Bob Johnson <sip:Bob@131.160.1.112>

Content-Type: application/sdp

Content-Length: 154

v=0

o=Bob 2891234321 2891234321 IN IP4 131.160.1.112

s=Let us talk for a while

c=IN IP4 131.160.1.112

t=0 0

m=audio 41000 RTP/AVP 0

当通话结束时，Bob发送一个Bye消息给Laura，Laura随后回应200 OK给Bob，至此通话结束。

参考资料：

1. “RFC 3261”- Section 4，Section 12，Section 17，Section 24；

2. “SIP Demystified”- Chapter 4， Chapter 5；

From: http://blog.csdn.net/minico/archive/2010/07/14/5734820.aspx

本文链接

FreeSwitch Sip【转】

2011-03-04T08:34:00Z

在继续学习 FreeSWITCH 之前我们有必要来学习一下 SIP 协议，因为它是 FreeSWITCH 的核心。但即使如此，讲清楚 SIP 必然需要很大篇幅，本书是关于 FreeSWITCH 的，而重点不是 SIP。因此，我将仅就理解 FreeSWITCH 必需的一些概念加以通俗的解释，更严肃一些的请参阅其它资料或 RFC（Request For Comments）。

SIP 的概念和相关元素

会话初始协议（Session Initiation Protocol）是一个控制发起、修改和终结交互式多媒体会话的信令协议。它是由 IETF（Internet Engineering Task Force，Internet工程任务组）在 RFC 2543 中定义的。最早发布于 1999 年 3 月，后来在 2002 年 6 月又发布了一个新的标准 RFC 2361。

SIP 是一个基于文本的协议，在这一点上与 HTTP 和 SMTP 相似。我们来对比一个简单的 SIP 请求与 HTTP 请求：

GET /index.html HTTP/1.1

INVITE sip:seven@freeswitch.org.cn SIP/2.0

请求由三部分组成。在 HTTP 中， GET 指明一个获取资源（文件）的动作，而 /index.html 则是资源的地址，最后是协议版本号。而在 SIP 中，INVITE 表示发起一次请求，seven@freeswitch.org.cn 为请求的地址，称为 SIP URI，最后也是版本号。其中，SIP URI很类似一个电子邮件，其格式为“协议:名称@主机”。与 HTTP 和 HTTPS 相对应，有 SIP 和 SIPS，后者是加密的；名称可以是一串数字的电话号码，也可以是字母表示的名称；而主机可以是一个域名，也可以是一个IP地址。

SIP 是一个对等的协议，类似 P2P。不像传统电话那样必须有一个中心的交换机，它可以在不需要服务器的情况下进行通信，只要通信双方都彼此知道对方地址（或者，只有一方知道另一方地址），如下图，bob 给 alice 发送一个 INVITE 请求，说“Hi, 一起吃饭吧...”，alice 说"好的，OK"，电话就通了。

在 SIP 网络中，alice 和 bob 都叫做用户代理（UA, User Agent）。UA 是在 SIP 网络中发起或响应 SIP 处理的逻辑功能。UA是有状态的，也就是说，它维护会话（或称对话）的状态。UA 有两种功能：一种是 UAC（UA Client用户代理客户端），它是发起 SIP 请求的一方，如上图的 bob。另一种是 UAS（UA Server），它是接受请求并发送响应的一方，如上图中的 alice。由于 SIP 是对等的，如果 alice 呼叫 bob 时（有时候 alice 也主动叫 bob 一起吃饭），alice 就称为 UAC，而 bob 则执行 UAS的功能。一般来说，UA 都会实现上述两种功能。

设想 bob 和 alice 是经人介绍认识的，而他们还不熟悉，bob 想请 alice 吃饭就需要一个中间人（M）传话，而这个中间人就叫代理服务器（Proxy Server）。还有另一种中间人叫做重定向服务器（Redirect Server），它类似于这样的方式工作──中间人 M 告诉 bob，我也不知道 alice 在哪里，但我老婆知道，要不然我告诉你我老婆的电话，你直接问她吧，我老婆叫 W。这样，M 就成了一个重定向服务器，而他老婆 W 则是真正的代理服务器。这两种服务器都是 UAS，它们主要是提供一对欲通话的 UA 之间的路由选择功能。具有这种功能的设备通常称为边界会话控制器（SBC，Service Border Controller）。

还有一种 UAS 叫做注册服务器。试想这样一种情况，alice 还是个学生，没有自己的手机，但它又希望 bob 能随时找到她，于是当她在学校时就告诉中间人 M 说她在学校，如果有事打她可以打宿舍的电话；而当她回家时也通知 M 说有事打家里电话。只要 alice 换一个新的位置，它就要向 M 重新“注册”新位置的电话，以让 M 能随时找到她，这时候 M 就是一个注册服务器。

最后一种叫做背靠背用户代理（B2BUA，Back-to-Back UA）。需要指出，其实 RFC 3261 并没有定义 B2BUA的功能，它只是一对 UAS 和 UAC的串联。FreeSWITCH 就是一个典型的 B2BUA，事实上，B2BUA 的概念会贯穿本书始终，所以，在此我们需要多花一点笔墨来解释。

我们来看上述故事的另一个版本：M 和 W 是一对恩爱夫妻。M 认识 bob 而 W 认识 alice。M 和 W 有意搓合两个年轻人，但见面时由于两人太腼腆而互相没留电话号码。事后 bob 相知道 alice 对他感觉如何，于是打电话问 M，M 不认识 alice，就转身问老婆 W （注意这次 M 没有直接把 W 电话给 bob），W 接着打电话给 alice，alice 说印象还不错，W 就把这句话告诉 M， M 又转过身告诉 bob。 M 和 W 一个面向 bob，一个对着 alice，他们两个合在一起，称作 B2BUA。在这里，bob 是 UAC，因为他发起请求；M 是 UAS，因为他接受 bob 的请求并为他服务；我们把 M 和 W 看做一个整体，他们背靠着背（站着坐着躺着都行），W 是 UAC，因为她又向 alice 发起了请求，最后 alice 是 UAS。其实这里UAC 和 UAS 的概念也不是那么重要，重要的是要理解这个背靠背的用户代理。因为事情还没有完，bob 一听说 alice 对他印象还不错，心花怒放，便想请 alice 吃饭，他告诉 M， M 告诉 W， W 又告诉 alice，alice 问去哪吃，W 又只好问 M， M 再问 bob…… 在这对年轻人挂断电话这前， M 和 W 只能“背对背”的工作。

从上图可以看出，四个人其实全是 UA。从上面故事可以看出，虽然 FreeSWITCH 是 B2BUA，但也可以经过特殊的配置，实现一些代理服务器和重定向服务器的功能，甚至也可以从中间劈开，两边分别作为一个普通的 UA 来工作。这没有什么奇怪的，在 SIP 世界中，所有 UA 都是平等的。具体到实物，则 M 和 W 就组成了实现软交换功能的交换机，它们对外说的语言是 SIP，而在内部，它们则使用自己家的语言沟通。bob 和 alice 就分别成了我们常见的软电话，或者硬件的 SIP 电话。

SIP 注册

不像普通的固定电话网中，电话的地址都是固定的。因特网是开放的，alice 的 UA 可能在家也可能在学校，或者，在世界是任何角落，只要能上网，它就能与世界通信。为了让我们的 FreeSWITCH 服务器能找到它，它必须向服务器进行注册。通常的注册流程是：

Alice                          FreeSWITCH 
  |                                |
  |           REGISTER             |
  |------------------------------->|
  |   SIP/2.0 401 Unauthorized     |
  |<-------------------------------|
  |           REGISTER             |
  |------------------------------->|
  |   SIP/2.0 200 OK               |
  |                                |

我们用真正的注册流程进行说明。下面的 SIP 消息是在真正的 FreeSWITCH 中 trace 出来的。其中 FreeSWITCH 服务器的 IP 地址是 192.168.4.4，使用默认的端口号 5060，在这里，我们使用的是 UDP 协议。 alice 使用的 UAC 是 Zoiper，端口号是 5090（在我写作时它与 FreeSWITCH 在同一台机器上，所以不能再使用端口 5060）。其中每个消息短横线之间的内容都是 FreeSWITCH 中输出的调试信息，不是 SIP 的一部分。

------------------------------------------------------------------------
recv 584 bytes from udp/[192.168.4.4]:5090 at 12:30:57.916812:
------------------------------------------------------------------------
REGISTER sip:192.168.4.4;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-d9ed3bbae47e568b-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:alice@192.168.4.4:5090;rinstance=d42207a765c0626b;transport=UDP>
To: <sip:alice@192.168.4.4;transport=UDP>
From: <sip:alice@192.168.4.4;transport=UDP>;tag=9c709222
Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rev.5415
Allow-Events: presence
Content-Length: 0

recv 表明 FreeSWITCH 收到来自 alice 的消息。我们前面已经说进，SIP 是纯文本的协议，类似 HTTP，所以很容易阅读。

第一行的 REGISTER 表示是一条注册消息。
Via 是 SIP 的消息路由，如果 SIP 经过好多代理服务器转发，则会有多条 Via 记录。
Max-forwards 指出消息最多可以经过多少次转发，主要是为了防止产生死循环。
Contact 是 alice 家的地址，本例中，FreeSWITCH 应该能在 192.168.4.4 这台机器上的 5090 端口找到她。
To 和 From 先不管。
Call-ID 是本次 SIP 会话（Session）的标志。
CSeq 是一个序号，由于 UDP 是不可靠的协议，在不可靠的网络上可能丢包，所以有些包需要重发，该序号则可以防止重发引起的消息重复。
Expires 是说明本次注册的有效期，单位是秒。在本例中，alice 应该在一小时内再次向 FreeSWITCH 注册，防止 FreeSWITCH 忘掉她。实际上，大部分 UA 的实现都会在几十秒内就重新发一次注册请求，这在 NAT 的网络中有助于保持连接。
Allow 是说明 alice 的 UA 所能支持的功能，某些 UA 功能丰富，而某些 UA 仅有有限的功能。
User-Agent 是 UA 的型号。
Allow-Events 则是说明她允许哪些事件通知。
Content-Length 是消息体（Body）的长度，在这里，只有消息头（Header），没有消息体，因此长度为 0 。

------------------------------------------------------------------------
send 664 bytes to udp/[192.168.4.4]:5090 at 12:30:57.919364:
------------------------------------------------------------------------
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-d9ed3bbae47e568b-1---d8754z-;rport=5090
From: <sip:alice@192.168.4.4;transport=UDP>;tag=9c709222
To: <sip:alice@192.168.4.4;transport=UDP>;tag=QFXyg6gcByvUH
Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
CSeq: 1 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
WWW-Authenticate: Digest realm="192.168.4.4",
    nonce="62fb812c-71d2-4a36-93d6-e0008e6a63ee", algorithm=MD5, qop="auth"
Content-Length: 0

FreeSWITCH 需要验证 alice 的身分才允许她注册。在 SIP 中，没有发明新的认证方式，而是使用已有的 HTTP 摘要（Digest）方式来认证。401 消息表示未认证，它是 FreeSWITCH 对 alice 的响应。同时，它在本端生成一个认证摘要（WWW-Authenticate），一齐发送给 alice。

------------------------------------------------------------------------
recv 846 bytes from udp/[192.168.4.4]:5090 at 12:30:57.921011:
------------------------------------------------------------------------
REGISTER sip:192.168.4.4;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-dae1693be9f8c10d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:alice@192.168.4.4:5090;rinstance=d42207a765c0626b;transport=UDP>
To: <sip:alice@192.168.4.4;transport=UDP>
From: <sip:alice@192.168.4.4;transport=UDP>;tag=9c709222
Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
CSeq: 2 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rev.5415
Authorization: Digest username="alice",realm="192.168.4.4",
    nonce="62fb812c-71d2-4a36-93d6-e0008e6a63ee",
    uri="sip:192.168.4.4;transport=UDP",response="32b5ddaea8647a3becd25cb84346b1c3",
    cnonce="b4c6ac7e57fc76b85df9440994e2ede8",nc=00000001,qop=auth,algorithm=MD5
Allow-Events: presence
Content-Length: 0

alice 收到带有摘要的 401 后，后新发起注册请求，这一次，加上了根据收到的摘要和它自己的密码生成的认证信息（Authorization）。并且，你可以看到，CSeq 序号变成了 2。

------------------------------------------------------------------------
send 665 bytes to udp/[192.168.4.4]:5090 at 12:30:57.936940:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-dae1693be9f8c10d-1---d8754z-;rport=5090
From: <sip:alice@192.168.4.4;transport=UDP>;tag=9c709222
To: <sip:alice@192.168.4.4;transport=UDP>;tag=rrpQj11F86jeD
Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.4.4:5090;rinstance=d42207a765c0626b;transport=UDP>;expires=3600
Date: Tue, 27 Apr 2010 12:30:57 GMT
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Length: 0

FreeSWITCH 收到带有认证的注册消息后，核实 alice 身份，认证通过，回应 200 OK。如果失败，则回应 403 Forbidden 或其它失败消息，如下。

------------------------------------------------------------------------
send 542 bytes to udp/[192.168.4.4]:5090 at 13:22:49.195554:
------------------------------------------------------------------------
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-d447f43b66912a1b-1---d8754z-;rport=5090
From: <sip:alice@192.168.4.4;transport=UDP>;tag=c097e17f
To: <sip:alice@192.168.4.4;transport=UDP>;tag=yeecX364pvryj
Call-ID: ZjkxMGJmMjE4Y2ZiNjU5MzM5NDZkMTE5NzMzMzM0Mjc.
CSeq: 2 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Length: 0

你可以看到，alice 的密码是不会直接在 SIP 中传送的，因而一定程序上保证了安全（当然还是会有中间人，重放之类的攻击，我们留到后面讨论）。

SIP 呼叫流程

UA 间直接呼叫

上面我们说过，SIP 的 UA 是平等的，如果一方知道另一方的地址，就可以通信。我们先来做一个实验。在笔者的机器上，我启动了两个软电话（UA），一个是 bob 的 X-Lite（左），另一个是 alice 是 Zoiper。它们的 IP 地址都是 192.168.4.4，而端口号分别是 26000 和 5090，当 bob 呼叫 alice 时，它只需直接呼叫 alice 的 SIP 地址：sip:alice@192.168.4.4:5090。如图，alice 的电话正在振铃：

详细的呼叫流程图为：

bob               alice
|                     |
|    INVITE           |
|-------------------->|
|    100 Trying       |
|<--------------------|
|    180 Ringing      |
|<--------------------|
|    200 OK           |
|<--------------------|
|    ACK              |
|-------------------->|
|                     |
|<---RTP------------->|
|<---RTP------------->|
|<---RTP------------->|
|    ...              |
|                     |
|    BYE              |
|<--------------------|
|    200 OK           |
|-------------------->|
|                     |

首先 bob 向 alice 发送 INVITE 请求建立 SIP 连接，alice 的 UA 回 100 Trying 说我收到你的请求了，先等会，接着 alice 的电话开始振铃，并给对回消息 180 Ringing 说我这边已经振铃了，alice 一会就过来接电话，bob 的 UA 收到该消息后可以播放回铃音。接着 alice 接了电话，她发送 200 OK 消息给 bob，该消息是对 INVITE 消息的最终响应，而先前的 100 和 180 消息都是临时状态，只是表明呼叫进展的情况。 bob 收到 200 后向 alice 回 ACK 证实消息。 INVITE - 200 - ACK 完成三次握手，它们合在一起称作一个对话（Dialogue）。这时候 bob 已经在跟 alice 能通话了，他们通话的内容（语音数据）是在SIP之外的 RTP 包中传递的，我们后面再详细讨论。

最后，alice 挂断电话，向 bob 送 BYE 消息，bob 收到 BYE 后回送 200 OK，通话完毕。其中 BYE 和 200 OK 也是一个对话，而上面的所有消息，称作一个会话（Session）。

反过来也一样，alice 可以直接呼叫 bob 的地址： sip:bob@192.168.4.4:26000。

上面描述了一个最简单的 SIP 呼叫流程。实际上，SIP 还有其它一些消息，它们大致可分为请求和响应两类。请求由 UAC 发出，到达 UAS 后， UAS 回送响应消息。某些响应消息需要证实（ACK），以完成三次握手。其中请求消息包括 INVITE、ACK、OPTIOS、BYE、CANCEL、REGISTER 以及一些扩展 re-INVITE、PRACK、SUBSCRIBE、NOTIFY、UPDATE、MESSAGE、REFER等。而响应消息则都包含一个状态码。跟 HTTP 响应类似，状态码有三位数字组成。其中，1xx 组的响应为临时状态，表明呼叫进展的情况；2xx 表明请求已成功处理；3xx 表明 SIP 请求需要转向到另一个 UAS 处理；4xx 表明请求失败，这种失败一般是由客户端或网络引起的，如密码错误等；5xx 为服务器内部错误；6xx 为更严重的错误。

通过 B2BUA 呼叫

在真实世界中，bob 和 alice 肯定要经常改变位置，那么它们的 SIP 地址也会相应改变，并且，如果他们之中有一个或两个处于 NAT 的网络中时，直接通信就更困难了。所以，他们通常会借助于一个服务器来相互通信。通过注册到服务器上，他们都可以获得一个服务器上的 SIP 地址。注册服务器的地址一般是不变的，因此他们的 SIP 地址就不会发生变化，因而，他们总是能够进行通信。

我们让他们两个都注册到 FreeSWITCH 上。上面已经说过，FreeSWITCH 监听的端口是 SIP 默认的端口 5060。bob 和 alice 注册后，他们分别获得了一个服务器的地址（SIP URI）：sip:bob@192.168.4.4 和 sip:alice@192.168.4.4（默认的端口号 5060 可以省略）。

下面是 bob 呼叫 alice 的流程。需要指出，如果 bob 只是发起呼叫而不接收呼叫，他并不需要向 FreeSWITCH 注册（有些软交换服务器需要先注册才能发起呼叫，但 SIP 是不强制这么做的）。

------------------------------------------------------------------------
recv 1118 bytes from udp/[192.168.4.4]:26000 at 13:31:39.938891:
------------------------------------------------------------------------
INVITE sip:alice@192.168.4.4 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-56adad736231f024-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:bob@192.168.4.4:26000>
To: "alice"<sip:alice@192.168.4.4>
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1014k stamp 47051
Content-Length: 594

上面的消息中省略了 SDP 的内容，我们将留到以后再探讨。bob 的 UAC 通过 INVITE 消息向 FreeSWITCH 发起请求。bob 的 UAC 用的是 X-Lite（User-Agent），它运行在端口 26000 上（实际上，它默认在端口也是 5060，但由于在我的实验环境下它也是跟 FreeSWITCH 运行在一台机器上，已被占用，因此它需要选择另一个端口）。其中，From 为主叫用户的地址，To 为被叫用户的地址。此时 FreeSWITCH 作为一个 UAS 接受请求并进行响应。它得知 bob 要呼叫 alice，需要在自己的数据库中查找 alice 是否已在服务器上注册，好知道应该怎么找到 alice。但在此之前，它先通知 bob 它已经收到了他的请求。

------------------------------------------------------------------------
send 345 bytes to udp/[192.168.4.4]:26000 at 13:31:39.940278:
------------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-56adad736231f024-1---d8754z-;rport=26000
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
To: "alice"<sip:alice@192.168.4.4>
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 1 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Content-Length: 0

FreeSWITCH 通过 100 Trying 消息告诉 bob “我已经收到你的消息了，别着急，我正在联系 alice 呢...” 该消息称为呼叫进展消息。

------------------------------------------------------------------------
send 826 bytes to udp/[192.168.4.4]:26000 at 13:31:39.943392:
------------------------------------------------------------------------
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-56adad736231f024-1---d8754z-;rport=26000
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
To: "alice" <sip:alice@192.168.4.4>;tag=B4pem31jHgtHS
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 1 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, line-seize, call-info, sla,
    include-session-description, presence.winfo, message-summary, refer
Proxy-Authenticate: Digest realm="192.168.4.4",
    nonce="31c5c3e0-cc6e-46c8-a661-599b0c7f87d8", algorithm=MD5, qop="auth"
Content-Length: 0

但就在此时，FreeSWITCH 发现 bob 并不是授权用户，因而它需要确认 bob 的身份。它通过发送带有 Digest 验证信息的 407 消息来通知 bob（注意，这里与注册流程中的 401 不同）。

------------------------------------------------------------------------
recv 319 bytes from udp/[192.168.4.4]:26000 at 13:31:39.945314:
------------------------------------------------------------------------
ACK sip:alice@192.168.4.4 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-56adad736231f024-1---d8754z-;rport
To: "alice" <sip:alice@192.168.4.4>;tag=B4pem31jHgtHS
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 1 ACK
Content-Length: 0

bob 回送 ACK 证实消息向 FreeSWITCH 证实已收到认证要求。并重新发送 INVITE，这次，附带了验证信息。

------------------------------------------------------------------------
recv 1376 bytes from udp/[192.168.4.4]:26000 at 13:31:39.945526:
------------------------------------------------------------------------
INVITE sip:alice@192.168.4.4 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-87d60b47b6627c3a-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:bob@192.168.4.4:26000>
To: "alice"<sip:alice@192.168.4.4>
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Proxy-Authorization: Digest username="bob",realm="192.168.4.4",
    nonce="31c5c3e0-cc6e-46c8-a661-599b0c7f87d8",
    uri="sip:alice@192.168.4.4",response="327887635344405bcd545da06763c466",
    cnonce="c164b74f625ff2161bd8d47dba3a0ee2",nc=00000001,qop=auth,
    algorithm=MD5
User-Agent: X-Lite release 1014k stamp 47051
Content-Length: 594

这里也省略了 SDP 消息体。

------------------------------------------------------------------------
send 345 bytes to udp/[192.168.4.4]:26000 at 13:31:39.946349:
------------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-87d60b47b6627c3a-1---d8754z-;rport=26000
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
To: "alice"<sip:alice@192.168.4.4>
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 2 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Content-Length: 0

FreeSWITCH 重新回 100 Trying，告诉 bob 呼叫进展情况。

至此，bob 与 FreeSWITCH 之间的通信已经初步建立，这种通信的通道称作一个信道（channel）。该信道是由 bob 的 UA 和 FreeSWITCH 的一个 UA 构成的，我们称它为 FreeSWITCH 的一条腿，叫做 a-leg。

接下来 FreeSWITCH 要建立另一条腿，称为 b-leg。它通过查打本地数据库，得到了 alice 的位置，接着启动一个 UA（用作 UAC），向 alice 发送 INVITE 消息。如下：

------------------------------------------------------------------------
send 1340 bytes to udp/[192.168.4.4]:5090 at 13:31:40.028988:
------------------------------------------------------------------------
INVITE sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4;rport;branch=z9hG4bKey90QUyHZQXNN
Route: <sip:alice@192.168.4.4:5090>;rinstance=e7d5364c81f2b879;transport=UDP
Max-Forwards: 69
From: "Bob" <sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
To: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 130069214 INVITE
Contact: <sip:mod_sofia@192.168.4.4:5060>
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, line-seize, call-info, sla,
    include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 313
X-FS-Support: update_display
Remote-Party-ID: "Bob" <sip:bob@192.168.4.4>;party=calling;screen=yes;privacy=off

你可以看到，该INVITE 的 Call-ID 与前面的不同，说明这是另一个 SIP 会话（Session）。另外，它还多了一个 Remote-Party-ID，它主要是用来支持来电显示。因为，在 alice 的话机上，希望显示 bob 的号码，显示呼叫它的那个 UA（负责 b-leg的那个 UA）没什么意义。与普通的 POTS 电话不同，在 SIP 电话中，不仅能显示电话号码（这里是 bob），还能显示一个可选的名字（“Bob”）。这也说明了 FreeSWITCH 这个 B2BUA 本身是一个整体，它虽然是以一个单独的 UA 呼叫 alice，但还是跟负责 bob 的那个 UA 有联系--就是这种背靠背的串联。

------------------------------------------------------------------------
recv 309 bytes from udp/[192.168.4.4]:5090 at 13:31:40.193634:
------------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.4.4;rport=5060;branch=z9hG4bKey90QUyHZQXNN
To: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>
From: "Bob" <sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 130069214 INVITE
Content-Length: 0

跟上面的流程差不多，alice回的呼叫进展。此时，alice 的 UA 开始振铃。

------------------------------------------------------------------------
recv 431 bytes from udp/[192.168.4.4]:5090 at 13:31:40.193816:
------------------------------------------------------------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.4.4;rport=5060;branch=z9hG4bKey90QUyHZQXNN
Contact: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>
To: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>;tag=3813e926
From: "Bob"<sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 130069214 INVITE
User-Agent: Zoiper rev.5415
Content-Length: 0

180也是呼叫进展消息，它说明，我这边已经准备好了，alice 的电话已经响了，她听到了一会就会接听。

send 1125 bytes to udp/[192.168.4.4]:26000 at 13:31:40.270533:
------------------------------------------------------------------------
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-87d60b47b6627c3a-1---d8754z-;rport=26000
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
To: "alice" <sip:alice@192.168.4.4>;tag=cDg7NyjpeSg4m
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 2 INVITE
Contact: <sip:alice@192.168.4.4:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, line-seize, call-info, sla,
    include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 267
Remote-Party-ID: "alice" <sip:alice@192.168.4.4>

FreeSWITCH 在收到 alice 的 180 Ringing 消息后，便告诉 bob 呼叫进展情况，183 与 180 不同的是，它包含 SDP，即接下来它会向 bob 发送 RTP 的媒体流，就是回铃音。

------------------------------------------------------------------------
recv 768 bytes from udp/[192.168.4.4]:5090 at 13:31:43.251980:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.4;rport=5060;branch=z9hG4bKey90QUyHZQXNN
Contact: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>
To: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>;tag=3813e926
From: "Bob"<sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 130069214 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rev.5415
Content-Length: 226

alice 接听电话以后，其 UA 向 FreeSWITCH 送 200 OK，即应答消息。

------------------------------------------------------------------------
send 436 bytes to udp/[192.168.4.4]:5090 at 13:31:43.256692:
------------------------------------------------------------------------
ACK sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4;rport;branch=z9hG4bKF72SSpFNv0K8g
Max-Forwards: 70
From: "Bob" <sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
To: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>;tag=3813e926
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 130069214 ACK
Contact: <sip:mod_sofia@192.168.4.4:5060>
Content-Length: 0

FreeSWITCH 向 alice 回送证实消息，证实已经知道了。至此，b-leg已经完全建立完毕，多半这时 alice 已经开始说话了：“Hi, bob，你好……”

------------------------------------------------------------------------
send 1135 bytes to udp/[192.168.4.4]:26000 at 13:31:43.293311:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-87d60b47b6627c3a-1---d8754z-;rport=26000
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
To: "alice" <sip:alice@192.168.4.4>;tag=cDg7NyjpeSg4m
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 2 INVITE
Contact: <sip:alice@192.168.4.4:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, line-seize, call-info, sla,
    include-session-description, presence.winfo, message-summary, refer
Session-Expires: 120;refresher=uas
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 267
Remote-Party-ID: "alice" <sip:alice@192.168.4.4>

与此同时，它也给 bob 送应答消息，告诉他电话已经接通了，可以跟 alice 说话了。在需要计费的情况下，应该从此时开始对 bob 的电话计费。bob 的 UA 收到该消息后启动麦克风让 bob 讲话。

------------------------------------------------------------------------
recv 697 bytes from udp/[192.168.4.4]:26000 at 13:31:43.413025:
------------------------------------------------------------------------
ACK sip:alice@192.168.4.4:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:26000;branch=z9hG4bK-d8754z-ef53864320037c04-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:bob@192.168.4.4:26000>
To: "alice"<sip:alice@192.168.4.4>;tag=cDg7NyjpeSg4m
From: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 2 ACK
Proxy-Authorization: Digest username="bob",realm="192.168.4.4",
    nonce="31c5c3e0-cc6e-46c8-a661-599b0c7f87d8",
    uri="sip:alice@192.168.4.4",response="327887635344405bcd545da06763c466",
    cnonce="c164b74f625ff2161bd8d47dba3a0ee2",nc=00000001,qop=auth,
    algorithm=MD5
User-Agent: X-Lite release 1014k stamp 47051
Content-Length: 0

bob 在收到应答消息后也需要回送证实消息。至此 a-leg 也建立完毕。双方正常通话。

[][][][][][] 此处省略 5000 字 [][][][][]

------------------------------------------------------------------------
recv 484 bytes from udp/[192.168.4.4]:5090 at 13:31:49.949240:
------------------------------------------------------------------------
BYE sip:mod_sofia@192.168.4.4:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-2146ae0ddd113efe-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>
To: "Bob"<sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
From: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>;tag=3813e926
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 2 BYE
User-Agent: Zoiper rev.5415
Content-Length: 0

终于聊完了，alice 挂断电话，发送 BYE 消息。

------------------------------------------------------------------------
send 543 bytes to udp/[192.168.4.4]:5090 at 13:31:49.950425:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-2146ae0ddd113efe-1---d8754z-;rport=5090
From: <sip:alice@192.168.4.4:5090;rinstance=e7d5364c81f2b879;transport=UDP>;tag=3813e926
To: "Bob"<sip:bob@192.168.4.4>;tag=Dp9ZQS3SB26pg
Call-ID: 0d74ac35-cca4-122d-81a2-2990e5b2bd3e
CSeq: 2 BYE
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Length: 0

FreeSWITCH 返回 OK，b-leg 释放完毕。

------------------------------------------------------------------------
send 630 bytes to udp/[192.168.4.4]:26000 at 13:31:50.003165:
------------------------------------------------------------------------
BYE sip:bob@192.168.4.4:26000 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4;rport;branch=z9hG4bKggvjUH0rS99tc
Max-Forwards: 70
From: "alice" <sip:alice@192.168.4.4>;tag=cDg7NyjpeSg4m
To: "Bob" <sip:bob@192.168.4.4>;tag=15c8325a
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 130069219 BYE
Contact: <sip:alice@192.168.4.4:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
    NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0

接下来 FreeSWITCH 给 bob 发送 BYE，通知要拆线了。出于对 bob 负责，它包含了挂机原因（Hangup Cause），此处 NOMAL_CLEARING 表示正常释放。

------------------------------------------------------------------------
recv 367 bytes from udp/[192.168.4.4]:26000 at 13:31:50.111765:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.4;rport=5060;branch=z9hG4bKggvjUH0rS99tc
Contact: <sip:bob@192.168.4.4:26000>
To: "Bob"<sip:bob@192.168.4.4>;tag=15c8325a
From: "alice"<sip:alice@192.168.4.4>;tag=cDg7NyjpeSg4m
Call-ID: YWEwYjNlZTZjOWZjNDg3ZjU3MjQ3MTA1ZmQ1MDM5YmQ.
CSeq: 130069219 BYE
User-Agent: X-Lite release 1014k stamp 47051
Content-Length: 0

bob 回送 OK，a-leg 释放完毕，通话结束。从下图可以很形象地看出 FreeSWITCH 的两条“腿”-- a-leg 和 b-leg。

整个呼叫流程图示如下：

bob (UAC)           [ UAS-UAC ]          (UAS) alice
 |                     |   |                     |
 |   INVITE            |   |                     |
 |-------------------->|   |                     |
 |   100 Trying        |   |                     |
 |<--------------------|   |                     |
 |   407 Authentication Required                 |
 |<--------------------|   |                     |
 |   ACK               |   |                     |
 |-------------------->|   |                     |
 |   INVITE            |   |                     |
 |-------------------->|   |                     |
 |   100 Trying        |   |    INVITE           |
 |<--------------------<   >-------------------->|
 |                     |   |    100 Trying       |
 |                     |   |<--------------------|
 |   183 Progress      |   |    180 Ringing      |
 |<--------------------<   |<--------------------|
 |                     |   |    200 OK           |
 |                     |   |<--------------------|
 |   200 OK            |   |    ACK              |
 |<--------------------<   >-------------------->|
 |   ACK               |   |                     |
 |-------------------->|   |                     |
 |                                               |
 |                Call Connected                 |
 |                                               |
 |                     |   |     BYE             |
 |                     |   |<--------------------|
 |   BYE               |   |    200 OK           |
 |<--------------------<   >-------------------->|
 |   200 OK            |   |                     |
 |-------------------->|   |                     |
 |                     |   |                     |

从流程图可以看出，右半部分跟上一节“UA间直接呼叫”一样，而左半部分也类似。这就更好的说明了实际上有 4 个 UA （两对）参与到了通信中，并且，有两个 Session。

再论 SIP URI

上面我们介绍了一些 FreeSWITCH 的基本概念，并通过一个真正的呼叫流程讲解了一下 SIP。由于实验中所有 UA 都运行在一台机器上，这可能会引起迷惑，如果我们有三台服务器，那么情况可能是：

                       /---------------\
                    |  FreeSWITCH   |
                    |  192.168.0.1  |
                    \ --------------/
sip:bob@192.168.0.1    /          \     sip:alice@192.168.0.1
                      /            \
                     /              \
  /-----------------\               /-----------------\
  |  bob            |               |  alice          |
  |  192.168.0.100  |               |  192.168.0.200  |
  \-----------------/               \-----------------/

  sip:bob@192.168.0.100                sip:alice@192.168.0.200

alice 注册到 FreeSWITCH，bob呼叫她时，使用她的服务器地址，即 sip:alice@192.168.0.1，FreeSWITCH 接到请求后，查找本地数据库，发现 alice 的实际地址是 sip:alice@192.168.0.200，便可以建立呼叫。

SIP URI 除使用 IP 地址外，也可以使用域名，如 sip:alice@freeswitch.org.cn。更高级也更复杂的配置则需要 DNS 的 SRV 记录，在此就不做讨论了。

本文链接

SIP简介，第2部分：SIP SERVLET[转]

2011-03-04T07:35:00Z

摘要

会话发起协议(Session Initiation Protocol，SIP)是一个重要的信令协议，它正在迅速被电信业采用以构建下一代应用程序。Java是用于SIP开发的极好平台，尤其是在进行服务器端开发时。类似于HTTP servlet，SIP Servlet API使SIP服务的开发变得更轻松。本文将介绍SIP servlet技术，并提供一个带注释的例子。

简介

即时消息传递正在改变人们的生活。它是一个非常有用的工具，结合了电子邮件、Internet电话以及文件传输应用程序的优点。用户甚至可以看到谁在线、谁的状态为“忙碌”。当然了，人们可以用它来长时间地进行不创造任何效益的聊天。但是，员工也可以利用它在老板会见客户时向他发送极为重要的信息。

所以，市场上出现如此多的不同种类的即时消息传递应用程序也就不足为怪了。有这么多的选择应该是一件好事，可是如果员工使用的应用程序与老板使用的不同，那又会怎么样呢？这将是一个大问题，因为这些应用程序大多都使用专有的协议。

SIP为我们带来了福音。SIP很有可能会成为标准的即时消息传递协议。

在本文中，我将开发一个简单的SIP应用程序——一个允许SIP即时messenger （消息传递应用程序）彼此联系并互相传播消息的聊天室服务器端。

SIP SIMPLE

SIMPLE ，即SIP Instant Messaging and Presence Leveraging Extension（SIP即时消息和现场支持扩展）的缩写，是一个工作组以及一组SIP扩展。其中的一个扩展是MESSAGE消息。可以用它来发送包含文本和二进制内容的任意组合的即时消息。这种消息使用起来非常简单，这也是我决定使用它来开发第一个SIP应用程序的原因。

TextClient

为了测试我们的应用程序，我提供了一个小型SIP即时messenger应用程序（参见文章结尾处的“下载”部分）。该应用程序向其他messenger或服务器发送MESSAGE消息。用户界面中包含了客户端的地址、好友地址的输入字段、一个文本消息以及一个提交按钮。图1显示了正在运行的TextClient。

图1. 运行中的TextClient

要启动TextClient，只需使用以下命令：

java -jar textclient.jar dev2dev.textclient.TextClient username port

该命令使用JAIN SIP API参考实现作为一个SIP协议栈。我们提供了该工具的源代码，如果您希望了解更多，我推荐您读一下源代码。

ChatRoomServer

下面是示例应用程序的需求

聊天室是一个虚拟空间，不同的即时messenger应用程序可以在其中进行交互。传入聊天室的消息将向聊天室中其他所有的人进行广播。换句话说，所有的消息都可以被所有用户看到。这意味着，当一个消息到达服务器端应用程序时，用户的地址将被添加到一个列表中。然后消息将被发送到该列表中的所有用户。

此外，还可以实现“命令”。命令以正斜杠(/)开头，它不被广播，而是由服务器自己处理，用于特定功能。我将实现的命令包括：

/join：默默地进入一个聊天室，不广播任何消息。

/who：打印一份该聊天室所有用户的列表。

/quit：离开聊天室，不再有消息传入。

SIP Servlet API

SIP Servlet API (JSR 116)是一个服务器端接口，它描述了一个SIP组件或服务的容器。这正适合用于开发ChatRoomServer。下载该规范，并解压缩。生成的文件夹包括一些库(servlet.jar、sipservlet.jar)以及文档。我无法获得运行示例SIP servlet的参考实现，所以我想您也不必费心去找它了。

SIP servlet最核心的概念是包含。SIP服务是部署或运行在在一个容器或SIP应用服务器上的打包SIP servlet。容器提供了可供应用程序使用的许多服务，比如自动重试、消息调度和排队、分流和归并，以及状态管理。应用程序中只需包含高级的消息处理和业务逻辑。这使SIP服务的开发成为一件轻而易举的事情。

本文的目的不是要提供对SIP Servlet API技术的全面介绍。因此我只简要概述了该API和示例代码，更多信息请参见文章结尾处的“参考资料”部分。

服务器端代码

如果您曾经开发过HTTP servlet，那么服务器端的代码会让您感到非常熟悉。如果您还不知道什么是servlet，您应该首先了解一下。SIP Servlet规范是HTTP Servlet规范的扩展。其语法、容器行为，甚至方法名都是相似的。

下面我将详细分析该例子。它主要由3个部分组成：

生命周期方法

这些方法在启动或关闭servlet时被容器调用：

public class ChatRoomServer extends SipServlet {

/** Context attribute key to store user list. */
public static String THE_LIST="dev2dev.chatroomserver.userList";

/** Init parameter key to retrieve the chat room's address. */
public static String THE_NAME="dev2dev.chatroomserver.name";

/** This chat room server's address, retrieved from the init params. */
public String serverAddress;

/** This is called by the container when starting up the service. */
public void init() throws ServletException {
super.init();
getServletContext().setAttribute(THE_LIST,new ArrayList());
serverAddress = getServletConfig().getInitParameter(THE_NAME);
}

/** This is called by the container when shutting down the service. */
public void destroy() {
try
{
sendToAll(serverAddress, "Server is shutting down -- goodbye!");
} catch (Throwable e)
{ //ignore all errors when shutting down.
e.printStackTrace();
}
super.destroy();
}
...

在初始化方法中，我创建了一个所有会话共享的全局属性。这是用户的列表。我还获得了该聊天室的地址（servlet参数）以备将来使用。

消息处理方法

SIP servlet与HTTP servlet稍有不同。对于HTTP servlet，您处理传入的请求，并发送响应消息。而对于SIP servlet，可以发送和接收请求和响应。我将说明如何做到这一点。

当收到消息（请求或响应）时，容器将调用下面的方法。容器将按照下面图表的顺序调用这些方法，也可以重写这些方法来根据消息的类型处理消息：

void service(ServletRequest,ServletResponse) 如果对其进行重写，不要忘记调用super.service()。其默认实现调用以下方法之一：
void doRequest(SipServletRequest) 如果对其进行重写，不要忘记调用super.doRequest()。其默认实现调用以下方法之一：	void doResponse(SipServletResponse) 如果对其进行重写，不要忘记调用super.doResponse()。其默认实现调用以下方法之一：:
下列请求方法之一（自解释）： doAck(SipServletRequest) doBye(SipServletRequest) doCancel(SipServletRequest) doInfo(SipServletRequest) doInvite(SipServletRequest) doMessage(SipServletRequest) doNotify(SipServletRequest) doOptions(SipServletRequest) doPrack(SipServletRequest) doRegister(SipServletRequest) doRequest(SipServletRequest) doResponse(SipServletResponse) doSubscribe(SipServletRequest)	下列响应方法之一： doProvisionalResponse(SipServletResponse)—对应于1xx-类响应消息。 doSuccessResponse(SipServletResponse)—对应于2xx-类响应消息。 doRedirectResponse(SipServletResponse)—对应于3xx-类响应消息。 doErrorResponse(SipServletResponse)—对应于4xx-、5xx-以及6xx-类响应消息。

void service(ServletRequest,ServletResponse) 如果对其进行重写，不要忘记调用super.service()。其默认实现调用以下方法之一：

void doRequest(SipServletRequest)

如果对其进行重写，不要忘记调用super.doRequest()。

其默认实现调用以下方法之一：

void doResponse(SipServletResponse)

如果对其进行重写，不要忘记调用super.doResponse()。

其默认实现调用以下方法之一：:

下列请求方法之一（自解释）：

doAck(SipServletRequest)
doBye(SipServletRequest)
doCancel(SipServletRequest)
doInfo(SipServletRequest)
doInvite(SipServletRequest)
doMessage(SipServletRequest)
doNotify(SipServletRequest)
doOptions(SipServletRequest)
doPrack(SipServletRequest)
doRegister(SipServletRequest)
doRequest(SipServletRequest)
doResponse(SipServletResponse)
doSubscribe(SipServletRequest)

下列响应方法之一：

doProvisionalResponse(SipServletResponse)—对应于1xx-类响应消息。
doSuccessResponse(SipServletResponse)—对应于2xx-类响应消息。
doRedirectResponse(SipServletResponse)—对应于3xx-类响应消息。
doErrorResponse(SipServletResponse)—对应于4xx-、5xx-以及6xx-类响应消息。

例如，MESSAGE可以调用以下方法：

service()，传入一个SipServletRequest（必须进行类型转换）以及null
doRequest()
doMessage()

通常只重写最后一级的方法，除非使用了非标准的SIP消息，或者希望收集有关消息的统计信息。

下面是处理即时消息的代码：

/** This is called by the container when a MESSAGE message arrives. */
protected void doMessage(SipServletRequest request) throws
ServletException, IOException {

request.createResponse(SipServletResponse.SC_OK).send();

String message = request.getContent().toString();
String from = request.getFrom().toString();

//A user asked to quit.
if(message.equalsIgnoreCase("/quit")) {
sendToUser(from, "Bye");
removeUser(from);
return;
}

//Add user to the list
if(!containsUser(from)) {
sendToUser(from, "Welcome to chatroom " + serverAddress +
". Type '/quit' to exit.");
addUser(from);
}

//If the user is joining the chat room silently, no message
//to broadcast, return.
if(message.equalsIgnoreCase("/join")) {
return;
}

//We could implement more IRC commands here,
//see http://www.mirc.com/cmds.html
sendToAll(from, message);
}

/**
* This is called by the container when an error is received
* regarding a sent message, including timeouts.
*/
protected void doErrorResponse(SipServletResponse response)
throws ServletException, IOException {
super.doErrorResponse(response);
//The receiver of the message probably dropped off. Remove
//the receiver from the list.
String receiver = response.getTo().toString();
removeUser(receiver);
}

/**
* This is called by the container when a 2xx-OK message is
* received regarding a sent message.
*/
protected void doSuccessResponse(SipServletResponse response)
throws ServletException, IOException {
super.doSuccessResponse(response);
//We created the app session, we have to destroy it too.
response.getApplicationSession().invalidate();
}

第一个方法在收到一个MESSAGE消息时被调用。最初以一条200 OK消息响应，表明收到了消息。然后它处理服务器命令，比如/join。最后，它调用一个业务逻辑方法来广播传入的消息。

传入的错误响应消息表明上一个请求失败了。这可能意味着有一个用户被断开了。只需将该用户从列表中移除即可。

成功的响应消息表明上一个MESSAGE消息被即时messenger正确地接收了。因此不再需要该会话，可以将其删除了。通常，MESSAGE消息是以无状态的形式发送的，并不保存消息之间的连接信息。（对于INVITE消息来说，情况不是这样的，它打开一个有状态的会话直到发送BYE。）

业务逻辑代码

其余的代码由helper方法组成。前两个方法向即时messenger发送消息。要发送消息，使用一个工厂创建以下两项：

一个SipApplicationSession（稍后将详细介绍）
一个请求消息

此时，可以随心所欲地修改消息。在我们的例子中，我们在有效负载中添加即时消息文本。最后，发送该消息。

private void sendToAll(String from, String message)
throws ServletParseException, IOException {
SipFactory factory = (SipFactory)getServletContext().
getAttribute("javax.servlet.sip.SipFactory");

List list = (List)getServletContext().getAttribute(THE_LIST);
Iterator users = list.iterator();
while (users.hasNext()) { //Send this message to all on the list.
String user = (String) users.next();

SipApplicationSession session =
factory.createApplicationSession();
SipServletRequest request = factory.createRequest(session,
"MESSAGE", serverAddress, user);
String msg = from + " sent message:
" + message;
request.setContent(msg.getBytes(), "text/plain");
request.send();
}
}

private void sendToUser(String to, String message)
throws ServletParseException, IOException {
SipFactory factory = (SipFactory)getServletContext().
getAttribute("javax.servlet.sip.SipFactory");
SipApplicationSession session = factory.createApplicationSession();
SipServletRequest request = factory.createRequest(session,
"MESSAGE", serverAddress, to);
request.setContent(message.getBytes(), "text/plain");
request.send();
}

private boolean containsUser(String from) {
List list = (List)getServletContext().getAttribute(THE_LIST);
return list.contains(from);
}

private void addUser(String from) {
List list = (List)getServletContext().getAttribute(THE_LIST);
list.add(from);
}

private void removeUser(String from) {
List list = (List)getServletContext().getAttribute(THE_LIST);
list.remove(from);
}

}

部署描述符

对于HTTP servlet，还必须编写web.xml部署描述符。而在SIP servlet中，对应的文件是sip.xml，我们在其中列出SIP servlet、初始化参数以及映射（哪个SIP servlet处理哪些SIP消息）。关于该文件语法的更多信息，请参见SIP Servlet规范中15.5节的DTD。其语法类似于web.xml，但标签除外。它不会将一个URL模式映射到servlet，而是（基于字段和子字段的内容）描述一个条件，SIP请求必须满足这个条件才能被映射到servlet。SIP Servlet规范第11节描述了所有的字段、子字段以及用于该映射的条件。

注意，该映射只用于初始请求；同一个会话/对话中的后续请求由处理初始请求的同一servlet处理。

下面是用于ChatRoomServer的XML代码：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sip-app
PUBLIC "-//Java Community Process//DTD SIP Application 1.0//EN"
"http://www.jcp.org/dtd/sip-app_1_0.dtd">
<sip-app>
<servlet>
<servlet-name>ChatRoomServer</servlet-name>
<servlet-class>dev2dev.chatroomserver.ChatRoomServer</servlet-class>
<init-param>
<param-name>dev2dev.chatroomserver.name</param-name>

<param-value>sip:chatroomname</param-value>
</init-param>
</servlet>

<servlet-mapping>
<servlet-name>ChatRoomServer</servlet-name>
<pattern>
<and>
<equal>
<var>request.uri.user</var>

<value>chatroomname</value>
</equal>
<equal>
<var>request.method</var>
<value>MESSAGE</value>
</equal>
</and>
</pattern>
</servlet-mapping>

</sip-app>

代码看起来很复杂，其实并非如此。Servlet映射说明了：

如果请求URI的用户名部分等于chatroomname，则将传入的MESSAGE请求映射到ChatRoomServer Servlet。

该聊天室名称只是一个占位符。在编译过程中，会用实际的聊天室名称替换关键字“chatroomname”。

这么做有什么用呢？您可以将同样的服务部署多次，每次都使用其独有的聊天室名称，而消息可以自动发送到相应的servlet。

构建、打包、部署

需要对SIP servlet进行编译，并将其打包到SAR(Servlet ARchives)文件中。这些文件在功能上等效于WAR文件，结构也相同。参见图2：

图2. SAR文件结构

最后一步是部署，这根据SIP应用服务器的不同而不同。通常需要将SAR文件复制到一个部署文件夹中，然后部署应用程序。

下面的Ant脚本可以帮助部署：

结果

聊天室应用程序运行之后，试着通过运行两个TextClient实例来访问它。要确保运行在同一机器上的SIP应用程序使用的是不同的端口。下面的例子显示了运行在同一机器上的3个应用程序：

运行在ChatRoomServer上的SIP应用服务器，地址是sip:just4fun@10.0.2.69:5060。
地址为sip:snoopy71@10.0.2.69:5061的Text client。
地址为sip:maria119@10.0.2.69:5062的Text client。

图3显示了结果。

图3. TextClient与ChatRoomServer交互

复杂应用程序

我知道本文中的例子相对于我们通常要构建的应用程序来说有点过于简单了，现实中的大多数SIP应用程序都由大量代码组成。

会话和状态：通常，SIP应用程序是一个状态机(state machine)，其中呼叫或会话都是长时间保持的（有状态的），直到断开。对于SIP servlet，呼叫是由SipApplicationSession表示的，它可以带属性（状态）。在呼叫中，每个会话（呼叫的分支）由SipApplicationSession中的SipSession表示。（两人间的back-to-back会话要使用一个SipApplicationSession和两个SipSession。会议呼叫可能包含更多的SipSession。这些都可以带属性。容器会根据消息的上下文自动提供相应的会话对象。

分层设计：最糟糕的是将所有的代码放入单个的大型SIP servlet。应该按照相对独立的层来设计复杂的应用程序。一个明显的层就是包括连接池的数据库层。也可以包含一个与SIP信令分离的业务逻辑层。另一个方面是有效负载分析，它应该被构建为一个可重用的层。

其他技术：存在许多先进的SIP servlet技术，包括请求代理、重定向和循环、会话超时管理、身份验证、国际化、TCP支持、计时器、会话监听程序以及错误管理。很明显，本文并没有涵盖所有这些方面，但是您可以在SIP Servlet规范中找到相关内容。

例子：可以参见“参考资料”部分，其中有可以帮助您了解更复杂的SIP编程的例子。

结束语

标准促进了互操作性，从而促进了协作。而协作——不管它是用于朋友间的轻松聊天，还是用于重要的文件传输——都是一件好事。

SIP是一个大有前途的电信标准，而SIP Servlet API则是轻松快速地开发服务器端SIP应用程序的极佳方式。在本文中，我们通过一个简单的例子，概述了SIP servlet编程。希望通过本文，能够帮助您在协作的道路上迈出一大步。

本文简要介绍了SIP、它的使用场景，以及一些SIP语法。我们还了解了各种与SIP相关的Java技术。尽管本文不够详尽，我还是希望它能够激发您的兴趣，并促使您开始使用它。SIP的时代已经到来，现在使用它可以实现很多很酷的想法。
在本系列文章的第2部分中，我将说明如何使用SIP Servlet API编写一个聊天室应用程序。

参考资料

SIP Forum——SIP工作组的社区站点
SIP Center——另一个广受欢迎的社区站点
RFC 3261——SIP规范
SIP的相关RFC和草案
开源JAIN SIP堆栈
开源SIP软件电话

本文链接

SIP简介，第1部分：SIP初探[转]

2011-03-04T06:31:00Z

摘要

会话发起协议（Session Initiation Protocol，SIP）是一种信令协议，它对于通信业有着重要的意义。本文从技术上对SIP进行了一般性的介绍，并说明了SIP如何为通信解决方案提供重要支持。

简介

我曾经构想过一种软件，它可以“浮于”应用程序之上，提供辅助作用。这不是一个哑的“帮助”系统，而是一个活动的技术支持代理，可以在Internet上进行讨论。那时曾有人告诉我，“现有的工具、库、协议或带宽实现不了这样的要求！”

时代已经不同了！

许多人家中已经拥有基于DSL、光纤和其他技术的宽带网络。存在大量高质量的工具和库，无论是商业的还是开源的。标准驱动应用。现在是时候来实现上述创新思路了。

了解SIP

首先，我将向您介绍SIP，也就是会话发起协议。SIP是一种轻量级的可扩展请求/响应协议，用于在两个端点之间开始通信会话。这听起来是不是很熟悉？SIP在概念上源自于HTTP和SMTP，但是它的目的却不同。可以把SIP消息与CB（民用波段）隐语10-code和Q-signal进行比较。

图1.用于管理CB呼叫的隐语

在这个例子中，真正的消息包含在专用的呼叫协商消息中。

SIP是IETF于1999年提出的，在2002年进行了修订。RFC 3261对它进行了描述。本文中有关SIP的信息就选自RFC。对SIP存在很多扩展，这些扩展中的很多都能在SIP-related RFCs and drafts清单中找到。

SIP有哪些优点呢？通常情况下，两个端点使用它来协商一次“呼叫”。这里的协商包括介质（文本、语音等）、传输（通常是RTP、Real Time Protocol）和编码（codec）。一旦协商成功，两个端点就会使用选中的方法相互交谈——这就与SIP无关了。“呼叫”完成之后，SIP用于指示断开连接。因此，SIP最好用作一种信令机制。SIP及其扩展还提供一些相关功能，比如即时消息传递、注册和到场。

SIP术语中的端点叫做用户代理。它可以是“软件电话”、即时消息收发器、IP电话，甚至是手机。服务器用户代理提供集中式的服务，比如登记员、代理或应用服务器。

听起来SIP非常简单，而且它也确实简单。这种简单性对于协议的稳定很重要，而且它也没有降低协议的有用性，所以该协议得到了广泛的应用。

例如，考虑一下HTTP。协议本身的定义很少。但是使用它的方式多不胜数。SIP也是可以扩展的。存在大量针对SIP的扩展，它们涵盖了很多应用。现在，我们进一步来考察SIP，并分析它为什么会如此重要。

SIP的重要性

有人说，SIP对于通信，就像HTTP对于Web一样。

SIP对通信业产生了巨大的影响。从事蜂窝技术的公司已经决定为了未来的应用，对SIP进行标准化。VoIP (Voice over IP)供应商、Internet电话和即时消息传递应用程序（例如，Microsoft MSN Messenger）都准备基于SIP进行标准化。

目前已经存在一些信令协议和P2P技术。这就引发了一个问题：SIP相对于这些协议和技术有何优势？SIP具有以下的明显优点：

稳定性。该协议已经使用了多年，现在十分稳定。

速度。基于UDP的小型协议效率特别高。

灵活性。这个基于文本的协议十分容易扩展。

安全性。它提供像加密(SSL、S/MIME)和身份验证这样的功能。对SIP的扩展还提供其他安全性功能。

标准化。随着整个通信行业都在向SIP靠拢，SIP已经讯速成为一种标准。其他技术可能具有SIP所没有的优势，但是它们没有得到全球范围内的采用。

这意味着，如果您想让您的应用程序与其他工具、设备和服务器进行互操作，SIP是最佳选择。供应商对互操作性是很关注的，会定期开会对其产品进行测试。这些会议称为SIPit for SIP Interoperability Tests（以前叫做Bakeoff，是Pillsbury提出更改的）。

剖析SIP呼叫

现在，让我们更深入地了解这门技术。SIP通常基于UDP进行传输，但是SIP工具必须同时支持TCP。一条SIP消息由两部分组成：

信封（envelope），以头字段的形式描述一个请求或请求的结果（响应）。

有效负载（payload），即内容（可选），包含有关请求的数据。

信封是文本格式，但是内容可以是文本，也可以是二进制格式。

例如，让我们具体分析一次典型的SIP呼叫。在这个场景中，用户A想呼叫用户B。图2说明了这次呼叫：

图2. 一次典型的SIP呼叫

下面对所有的消息进行了解释：


1. User Agent A发送一个SIP请求INVITE给User Agent B，表达User A想跟User B进行谈话的愿望。这个请求包含语音流协议的细节。payload中使用会话描述协议（Session Description Protocol，SDP)就是为此目的。SDP消息包含一个清单，其内容为User A支持的所有介质编码。（这些编码使用RTP进行传输。）	INVITE sip:UAB@example.com SIP/2.0 Via: SIP/2.0/UDP 10.20.30.40:5060 From: UserA <sip:UAA@example.com>;tag=589304 To: UserB <sip:UAB@example.com> Call-ID: 8204589102@example.com CSeq: 1 INVITE Contact: <sip:UserA@10.20.30.40> Content-Type: application/sdp Content-Length: 141 v=0 o=UserA 2890844526 2890844526 IN IP4 10.20.30.40 s=Session SDP c=IN IP4 10.20.30.40 t=3034423619 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
2. User Agent B读取该请求，然后告诉User Agent A它已经收到请求。	SIP/2.0 100 Trying From: UserA <sip:UAA@example.com>;tag=589304 To: UserB <sip:UAB@example.com> Call-ID: 8204589102@example.com CSeq: 1 INVITE Content-Length: 0
3.当电话响铃时，User Agent B发送临时消息（响铃）给User Agent A，这样它就不会超时和放弃。	SIP/2.0 180 Ringing From: UserA <sip:UAA@example.com>;tag=589304 To: UserB <sip:UAB@example.com>;tag=314159 Call-ID: 8204589102@example.com CSeq: 1 INVITE Content Length: 0
4.最终，User B决定接受呼叫。此时，User Agent B发送一个OK响应给User Agent A。在响应的payload中，还有另一条SDP消息。它包含一组两个用户代理都支持的介质编码。此时，双方正式处于呼叫中。使用200类型的响应可以接受所有类型的SIP请求。	SIP/2.0 200 OK From: UserA <sip:UAA@example.com>;tag=589304 To: UserB <sip:UAB@example.com>;tag=314159 Call-ID: 8204589102@example.com CSeq: 1 INVITE Contact: <sip:UserB@10.20.30.41> Content-Type: application/sdp Content-Length: 140 v=0 o=UserB 2890844527 2890844527 IN IP4 10.20.30.41 s=Session SDP c=IN IP4 10.20.30.41 t=3034423619 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
5. User Agent A最后使用一条ACK消息进行确认。对于这种请求类型来说，没有重试和响应消息，即使消息丢失。ACK只在INVITE消息中使用。	ACK sip:UAB@example.com SIP/2.0 Via: SIP/2.0/UDP 10.20.30.41:5060 Route: <sip:UserB@10.20.30.41> From: UserA <sip:UAA@example.com>;tag=589304 To: UserB <sip:UAB@example.com>;tag=314159 Call-ID: 8204589102@example.com CSeq: 1 ACK Content-Length: 0
6..两个用户代理现在使用最后一条SDP消息中选定的方法进行连接。	RTP使用PCMU/8000编码对在端口49170 & 3456上双向传输的音频数据进行打包。
7.在通信会话结束时，其中一个用户挂断。此时，这个用户的用户代理发送一个新的请求BYE。这条消息可以由任一方发送。	BYE sip:UAB@example.com SIP/2.0 Via: SIP/2.0/UDP 10.20.30.41:5060 To: UserB <sip:UAB@example.com>;tag=314159 From: UserA <sip:UAA@example.com>;tag=589304 Call-ID: 8204589102@example.com CSeq: 1 BYE Content-Length: 0
8.另一用户的用户代理接受该请求，然后使用一条OK消息作为应答。呼叫连接至此断开。	SIP/2.0 200 OK To: UserB <sip:UAB@example.com>;tag=314159 From: UserA <sip:UAA@example.com>;tag=589304 Call-ID: 8204589102@example.com CSeq: 1 BYE Content-Length: 0

SIP消息的第一行包含消息的类型和所使用的SIP版本（2.0）。在请求中，这一行还包含一个叫做SIP URI的地址。这代表消息的目的地。

这个例子说明了如何使用请求消息INVITE、ACK和BYE，以及200 OK响应消息。SIP中还存在许多其他消息。下面给出一些请求：

消息	用法
INVITE	呼叫一个用户代理，传送一次呼叫。
ACK	确认呼叫。
BYE	终止呼叫。
CANCEL	终止还未OK的呼叫。
REGISTER	提供一项注册服务，带有一个联系地址和可以用来代替的别名。例如，在前面的例子中，地址sip:UAA@example.com就是sip:UserA@10.20.30.40的别名。然后，注册服务器example.com就可以把呼叫转发给地址10.20.30.40。
OPTIONS	询问一个用户代理的“能力”（例如，该用户代理能够识别的消息和编码）。

现在给出一些经常使用的响应消息：

消息	用法
100 Trying	消息已收到，但是最终用户代理尚未进行处理。请等待。
180 Ringing	最终用户代理已经收到消息，正在提示用户。请等待。
200 OK	最终用户已经接受消息。
301 Moved Permanently & 302 Moved Temporarily	用户代理的地址已经改变，新的永久或临时地址位于Contact字段中。
400 Bad Request	普通错误消息。客户端不能识别消息。
401 Unauthorized & 407 Proxy Authentication Required	请使用证书重试。
404 Not Found	要联系的用户不存在或尚未注册。
408 Request Timeout	另一方没有响应。这意味着SIP消息永远不会OK。所有重试都将被丢弃。这并不意味着电话响太长时间（电话可以永远响铃）。

消息使用类似的头字段类型。下面给出其中的一些：

头字段	用法
From	SIP请求的发送者。
To	SIP请求的接受者。这通常与SIP URI相同（可以是一个“别名”或一个实际地址）。
Contact	用户代理的实际地址。
Call-ID	这并不是呼叫者的电话号码。它惟一地代表两个用户代理之间的完整呼叫或对话。所有相关的SIP消息都使用同一个Call-ID。例如，当一个用户代理收到一条BYE消息，根据Call-ID，它就知道要挂断哪次呼叫。
CSeq	消息的顺序编号。这在一次对话或一个Call-ID中是惟一的。这用于区别新的消息和“重试消息”。当一条初始消息没有及时OK时，重试就会进行，并会定时发送。
Content-Type	消息内payload的MIME类型。
Content-Length	payload的大小，以字节为单位。信封和payload之间由一空行隔开。

还有一些与消息路由选择功能相关的头字段，如：Via、Route和Record-Route。许多头字段提供像Accept、User-Agent和Supported这样的功能。其他头字段则提供像Authorization、Privacy和WWW-Authenticate这样的安全性功能。还有很多其他的头字段存在。此外，这些字段中许多都有缩写语法（比如，From = f，To = t，等等）。

SIP的其他功能

使用SIP及其扩展可以实现很多应用：

VoIP
视频会议
针对文本和数据的即时消息传递，比如MSN Instant Messenger
注册(我在线!)
到场(我的伙伴在不在?)
Click-to-talk(点击通话，即点击这里便可与一个技术支持代理交谈)
应答机器/互动式语音应答（Interactive Voice Response，IVR)系统(“请输入您的密码。请记录您的姓名。英文请按1，西班牙语请按2…”)
网络游戏，比如Quake和一些手机游戏（甚至基于语音和IM）
基于手机的应用程序
移动电子商务

基本上，如果是两个端点之间进行通信，SIP就能完成。
但是，关于活动的Web技术支持代理的想法又如何呢？现在我们能否使用SIP来实现它？我们能否使用Java来实现它？干脆点说，可以。

Java中的SIP

我经常使用SIP。我可以负责任地说，Java为SIP提供了绝佳的支持。Java技术的一个分支把与开发SIP应用程序相关的许多细节抽象出来，这对于SIP开发人员大有帮助。下面这些技术大部分位于JAIN (Java APIs for Integrated Networks)工作组中。

JAIN SIP API (JSR 32)
SIP Servlet API (JSR 116)
JAIN SIP Lite (JSR 125)
SIP API for J2ME (JSR 180)
JAIN SIMPLE Presence (JSR 164)
JAIN SIMPLE Instant Messaging (JSR 165)

其他相关技术有：

JAIN SDP (JSR 141)
Java Media Framework for RTP (J2SE可选包，并非JAIN的)

如果您希望开发一个客户端应用程序，就需要一个客户端SIP引擎或者“堆栈”。在这里可以找到一个优秀的开源Java SIP堆栈。它还支持SDP。如果不想自己开发SIP电话，您可以使用这个。

结束语

参考资料

SIP Forum——SIP工作组的社区站点
SIP Center——另一个广受欢迎的社区站点
RFC 3261——SIP规范
SIP的相关RFC和草案
开源JAIN SIP堆栈
开源SIP软件电话

本文链接

OPAL学习笔记 - Outgoing Call [转]

2011-03-02T04:33:00Z

(学习理解中，文字内容以后填加)

本文链接

OPAL学习笔记 - Incoming Call [转]

2011-03-02T04:32:00Z

(学习理解中，文字内容以后补充)

本文链接

OPAL学习笔记 - Start Listen[转]

2011-03-02T04:29:00Z

(学习理解中，文字内容稍后补充)

本文链接

OPAL学习笔记 - 构架核心类静态结构[转]

2011-03-02T04:26:00Z

(注：由于时间关系和学习目的，本系列学习笔记主要关注呼叫管理过程，不关注媒体流的创建、转发等媒体流相关细节。）

OPAL - Open Phone Abstraction Library，是一套开放源码库，主要用于基于包交换网络的、基于H.323和SIP协议的多媒体通讯应用开发。在OPAL库的框架之下，你可以方便的扩展其他媒体通讯协议，使得自己公司的多媒体通讯产品能与主流的产品（如H.323终端、H.323 MCU、SIP终端等）兼容。

OPAL对多媒体通讯系统的通讯协议进行高度抽象，形成了“协议抽象构架层”，主要包括以下类：

OpalManager
OPAL的核心管理类，库中所有其他组件的大部分事件都会被集中到OpalManager中，应用程序只南要通过其子类对这些接口进行重载来获得OPAL系统的大部分事件通知；另外，OpalManager还提供了呼叫管理、连接管理、媒体流管理等管理接口。
注意：OpalManager在OPAL中被设计为“单件”，由应用程序保证系统中只有一个该类或其子类的实例存在。
OpalCall
一个call（呼叫）由一个或多个connection（连接）对象组成，OpalCall类负责管理与一个call相关的多个connection以及协调它们之间行为。如：一个OpalCall管理了一个H323Connection对象和一个SIPConnection对象时，那么这个call就是两个协议之间的“网关”；在会议环境下，一个OpalCall可能会管理多个H323Connection或SIPConnection对象。
OpalConnection
connection表示的是一个到endpoint的连接，OpalConnection是所有connection的基类，不同的协议会有不同的子类来实现其协议相关的connection的特殊语义。
一个connection是一个call的一部分，它同时也与创建它的endpoint关联起来，以便进行这个connection与协议相关的一些管理。用户程序不能直接删除connection对象，它将由OpalManager指定的线程来删除。
根据协议相关信令和类接口，connection还负责在适当的时机创建和打开媒体流。
OpalEndPoint
这是endpoint的基类，每一种协议都通过继承一个OpalEndPoint的子类来管理其独自的子系统。如OPAL库中H323EndPoint表示H.323协议中的端点、而SIPEndPoint表示SIP协议中的端点等。需要注意的是，本机的声卡设备，在OPAL库中也被封装成了一个endpoint。
OpalMediaFormat
这个类描述了OPAL系统中使用的媒体格式。媒体格式是OPAL实体间传递的媒体数据的类型描述。如，音频编解码算法（G.723.1等）、视频编解码算法（H.263等），都称为媒体格式。
OpalMediaPatch
媒体流数据的“调度器件”。这个类是控制媒体数据转发的线程，它将数据从一个“source”OpalMediaStream对象，转发到一个或多个“sink”OpalMediaStream对象。

下图展示OPAL的“协议抽象构架层”的类结构

本文链接

新一代开源VoIP协议栈－－OPAL(OpenH323 v2)[转]

2011-03-02T03:53:00Z

OPAL是Open Phone Abstraction Library的字母缩写，仍然是Equivalence公司开发的开源VoIP协议栈，从2001年便开始开发了，直到现在还没有正式发布过一个版本，只能从CVS: http://cvs.sourceforge.net/viewcvs.py/openh323/opal下载最新的版本，而且现在的2.05bate版有着非常多的问题，但这些丝毫不能阻止我对OPAL的看好。OPAL仍然采用PWLIB作为开发库，最新的PWLIB实际已经只剩PTLIB,Equivalence公司已经停止了对PWLIB的GUI开发了，GUI全面转向更为强大的wxWindows。OPAL作为Openh323的下一代协议栈最大的特点是加入了对SIP协议的支持，OPAL保留了Openh323大部分代码，并加入了对EndPoint，Connection等抽象描述的基类，使得添加新的协议和设备变得更加简单和方便。

OPAL中最重要的类是新加的:OpalManager,它跟Openh323中的H323EndPoint地位一样，它定义了OPAL系统中最基本的操作，所以每个应用程序必须从OpalManager派生一个类，然后重载虚函数实现自己的操作。
OpalManager::SetUpCall(partyA,partyB,token); 呼叫，partyA是会话发起人，partyB是会话接受人
OpalManager::OnIncomingConnection（connection); 接听，返回TRUE则接听，返回FLASH则拒绝
OpalManager::AdjustMediaFormats(connection,mediaFormats); 调整媒体格式
OpalManager::ClearCall(token,reason,sync) 清除呼叫，sync如果为NULL则不等待快速返回
OpalEndPoint是描述端点的基类，H323,SIP,PSTN,IVR，LID,声卡的端点都是继承于这个类，在这里值得注意的是连声卡设备也看做一种端点。
OpalPCSSEndPoint则是EndPoing中比较重要的一个类，毕竟打电话还是声卡用的多，OpalPCSSEndPoint的构造函数必须引用派生的OpalManager类的实例。

下面具体例子SimpleOPAL来讲解：
opal = new MyManager;                                                           //新建一个MyManager的实例
if (opal->Initialise(args))                                                          //调用MyManager::Initialise()函数初始化
opal->Main(args);                                                                   //等待用户输入命令
cout << "Exiting " << GetName() << endl;
delete opal;                                                                             //擦pp
部分Initialise()函数代码：
SetVideoInputDevice(video);                                                    //设置输入视频设备
...
SetVideoOutputDevice(video);                                                  //输出视频设备
...
SetAudioJitterDelay(minJitter, maxJitter);                                 //声音抖动缓存的最小和最大值
...
SetMediaFormatMask(args.GetOptionString('D').Lines());          //屏蔽的媒体格式
SetMediaFormatOrder(args.GetOptionString('P').Lines());          //媒体格式的使用顺序
...
SetTranslationAddress(args.GetOptionString("translate"));         //设置外部IP地址
...
Set***Ports(rgs.GetOptionString("tcp-base").AsUnsigned(),
               args.GetOptionString("tcp-max").AsUnsigned());        //设置相关的端口
SetSTUNServer(args.GetOptionString("stun"));                         //使用STUN服务器
...
pcssEP = new MyPCSSEndPoint(*this);                                    //新建一个MyPCSSEndPoint实例
pcssEP->SetSoundDevice(args, "sound", PSoundChannel::Recorder)//设置相关的播放声音设备
...
h323EP = new H323EndPoint(*this);                                         //h323EP的初始化
h323EP->DisableFastStart(args.HasOption('f'));                        //关闭快速拨号模式
h323EP->DisableH245Tunneling(args.HasOption('T'));              //关闭H245通道模式
h323EP->AddAliasName(aliases[i]);                                         //添加昵称
h323EP->SetInitialBandwidth(initialBandwidth);                        //限制带宽
h323EP->StartListeners(listeners)                                             //现在才开始监听，默认是TCP:1720
h323EP->SetGatekeeperPassword(args.GetOptionString('p'));    //注册网守所需的密码
h323EP->UseGatekeeper(gkHost, gkIdentifer, gkInterface)       //注册网守
...
sipEP = new SIPEndPoint(*this);                                               //SIP也来了
sipEP->SetUserAgent(args.GetOptionString("sip-user-agent")); //设置用户代理,UserAgent就相当于最初openh323的endpoint
sipEP->SetProxy(args.GetOptionString("sip-proxy"));              //设置SIP代理,此处proxy相当于h323里的Gatekeeper
sipEP->SetMIMEForm(args.HasOption("use-long-mime"));         //MIME头的格式
sipEP->StartListeners(listeners)                                              //监听开始，默认是TCP:5060和UDP:5060
Main()函数部分代码：
if (pcssEP != NULL && !pcssEP->incomingConnectionToken) {    //小心，有电话来了
      if (cmd == "n")
        pcssEP->ClearCall(pcssEP->incomingConnectionToken,     //打死我都不接
    OpalConnection::EndedByRefusal);
      else if (cmd == "y")
        pcssEP->AcceptIncomingConnection(pcssEP->                  //喂，小莉吗？
    incomingConnectionToken);
    }
...
OpalCall * call = FindCallWithLock(currentCallToken);             //让我看看是那一个通话
if (call != NULL) {
cout << "Clearing call " << *call << endl;
call->Clear();                                                                      //废话那么多，打IP电话也要钱的，挂拉
call->Unlock();
...
if (potsEP != NULL)                                                                //是打电脑还是打座机呢？
SetUpCall("pots:*", params[1], currentCallToken);                 //打座机吧(PSTN)
else
SetUpCall("pc:*", params[1], currentCallToken);                    //打电脑不要钱，嘿嘿

OPAL中的例子MFC根本无法使用，Openphone的GUI使用了wxWindows，所以必须安装了wxWindows才能正常编译，opalgw这玩意我试过好多次根本无法让别人注册，看来OPAL要走的路还很长，不过Equivalence公司开发已经渐渐的从Openh323转向了OPAL,相信不久一个稳定的OPAL将会被发布.

本文链接