蜜果私塾：SIP協議學習

版權所有，轉載請注明出處：http://m.tkk7.com/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更通用一些.