會話發起協議（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說明了這次呼叫：
下面對所有的消息進行了解釋：
1. User Agent A發送一個SIP請求INVITE給User Agent B，表達User A想跟User B進行談話的願望。這個請求包含語音流協議的細節。payload中使用會話描述協議（Session Description Protocol，SDP)就是爲此目的。SDP消息包含一個清單，其內容爲User A支持的所有介質編碼。（這些編碼使用RTP進行傳輸。） INVITE
sip:[email protected]
SIP/2.0
Via: SIP/2.0/UDP 10.20.30.40:5060
From: UserA <sip:[email protected]>;tag=589304
To: UserB <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
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:[email protected]>;tag=589304
To: UserB <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
3.當電話響鈴時，User Agent B發送臨時消息（響鈴）給User Agent A，這樣它就不會超時和放棄。 SIP/2.0
180 Ringing
From: UserA <sip:[email protected]>;tag=589304
To: UserB <sip:[email protected]>;tag=314159
Call-ID: [email protected]
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:[email protected]>;tag=589304
To: UserB <sip:[email protected]>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
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:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.20.30.41:5060
Route: <sip:[email protected]>
From: UserA <sip:[email protected]>;tag=589304
To: UserB <sip:[email protected]>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
6..兩個用戶代理現在使用最後一條SDP消息中選定的方法進行連接。 RTP使用PCMU/8000編碼對在端口49170 & 3456上雙向傳輸的音頻數據進行打包。
7.在通信會話結束時，其中一個用戶掛斷。此時，這個用戶的用戶代理髮送一個新的請求BYE。這條消息可以由任一方發送。 BYE
sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.20.30.41:5060
To: UserB <sip:[email protected]>;tag=314159
From: UserA <sip:[email protected]>;tag=589304
Call-ID: [email protected]
CSeq: 1 BYE
Content-Length: 0
8.另一用戶的用戶代理接受該請求，然後使用一條OK消息作爲應答。呼叫連接至此斷開。 SIP/2.0
200 OK
To: UserB <sip:[email protected]>;tag=314159
From: UserA <sip:[email protected]>;tag=589304
Call-ID: [email protected]
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:[email protected]就是sip:[email protected]的別名。然後，註冊服務器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、它的使用場景，以及一些SIP語法。我們還了解了各種與SIP相關的Java技術。儘管本文不夠詳盡，我還是希望它能夠激發您的興趣，並促使您開始使用它。SIP的時代已經到來，現在使用它可以實現很多很酷的想法。
在本系列文章的第2部分中，我將說明如何使用SIP Servlet API編寫一個聊天室應用程序。
參考資料
SIP Forum——SIP工作組的社區站點
SIP Center——另一個廣受歡迎的社區站點
RFC 3261——SIP規範
SIP的相關RFC和草案
開源JAIN SIP堆棧
開源SIP軟件電話
原文出處:http://dev2dev.bea.com/pub/a/2005/09/introduction-sip-part-1.html