蜜果私塾：SIP协议学习

版权所有，转载请注明出处：http://www.blogjava.net/amigoxie/archive/2009/07/15/286793.html 

1.     相关规范

RFC3261：基本的会话初始协议，见http://www.ietf.org/rfc/rfc3261.txt；

RFC3264：定义了SDP的提供应答模式，见http://www.ietf.org/rfc/rfc3264.txt；

RFC3725：3PCC全称Third Party Call Control，是指由第三方来实现的主被叫通话。SIP的3PCC流程定义于RFC3725中。见http://www.ietf.org/rfc/rfc3725.txt

2.     相关概念

2.1   SIP简介

SIP是应用层控制协议，可以创建，修改，以及中止一个或多个参与者的对话。在INTERNET上有很多这样的应用，我们需要建立和管理一个对话，这个对话是用来在一组参与者的连接上来进行数据交换。因为一些参与者实际的行为，操作变得复杂了。比如用户可能在终端移动；他们可能有多个地址；也可能在用多种媒体形式进行交流－有时还是同步的。一组协议被用来传送不同形式的实时多媒体对话数据，比如语音数据，视频数据，文件消息等等。SIP和其他协议一起工作，使INTERNET终端找到另一个终端，然后用他们所取得一致的特性进行交流。

2.2   offer/answer机制

定义与RFC3264，利用该机制两个实体可以使用SDP对他们之间的多媒体会话达成一致。在该模式中，一个参加者向另一个参加者提供它期望建立的会话的描述，另一个参加者应答它期望建立的对话。

提供应答模式是SIP必须使用的基本机制。

2.3   3PCC

3PCC全称Third Party Call Control，是指由第三方来实现的主被叫通话。

在常见的业务流程中，应用服务器作为第三方，需要根据业务流程控制主叫、被叫、媒体服务器之间的对话的建立和切断。所以应用服务器上的信令流程都以3pcc为基础。

RFC3725中定义了四种基本的3pcc流程，在后面将详细描述，3PCC的目标是让要建立会话的两个网元进行完整的offer/answer协商。

3.     offer/answer

3.1   原则

1） 在一次提供应答完成之前，不能进行新的提供应答协商；

2） 提供者在没有收到应答的时候，不能发送新的提供；

3） 应答者在没有发送应答的时候，也不能发送新的提供

3.2   流程

根据3.1中的原则，可知如下流程都是正确的：

流程1：

 流程2：

如下的流程在offer还没有得到响应者应答的时候发送了新的offer，因此是错误流程：

如下的流程发送者在offer还没有得到响应应答的时候，由响应者发送了新的offer，因此也是错误流程：

4.     3PCC

4.1   3PCC基本流程1

在RFC3725中定义的流程1如下所示：

该流程是比较常用的流程，用于A、B双方在收到INVITE后都能立刻回送200OK的场景。当B不能立刻回送200 OK的情况（可能耗时很多秒），A需要多次进行重发，此时使用那个这种流程不合适。

4.2   3PCC基本流程2

在RFC3725中定义的流程2如下所示：

流程2从单边来说虽然遵守了offer/answer，但总体上并没有完全按照offer/answer实现，因为第（8）中带出来的sdp2并没有再次发送给B，有可能会造成单通的情况，不推荐使用。

4.3   3PCC基本流程3

在RFC3725中定义的流程3如下所示：

流程3是最为通用的流程，对于初始发起呼叫来说比较合适，不要求A、B立刻回200OK响应，也不会因此单通的情况。

4.4   3PCC基本流程4

在RFC3725中定义的流程4如下所示：

流程4和流程3差不多，对于初始发起呼叫来说比较合适，也不要求A、B立刻回200OK响应。由于大多数终端都不支持no media的sdp，所以流程3更通用一些.