Session Initiation Protocol﹝SIP﹞是一套定義於應用層的連線控制協 定，其主要功能在於多個參與者之間會議的建立、修改以及終止，會議可包 含網路視訊會議、網路電話連線以及多媒體資源的散佈，會議裡參與者可透 過群播、單點傳播甚至是合倂兩者的機制與其他參與者溝通。
SIP 通訊協定的訊息格式十分類似 HTTP﹝Hypertext Transport Protocol﹞，這個通訊協定的訊息是以 ISO10646 UTF-8 的純文字格式編 碼，以該方式做為傳遞的訊息格式，其優點在於無作業系統平台上的限制，
因而實作者無須考慮到發展平台之間的相異處，使用Java、Tcl 和 Perl 等 程式語言皆可輕易實作出來，而SIP 通訊協定最大的優勢是在它的彈性及延 伸性，加上SIP 的主要功能在建立視訊會議，相較於視訊會議期間的大量媒 體串流，建立會議之前所需要的額外SIP 控制訊息便不影響連線的品質。
SIP 訊息可分為請求﹝Request﹞和回應﹝Response﹞訊息，它是使用 RFC822 所定義的通用訊息格式﹝Generic-Message Format﹞，兩種訊息皆 包括起始行﹝start line﹞、一個以上的標頭欄位﹝headers﹞、一行空白行
﹝僅包括CRLF﹞以及選擇性(可有可無)的訊息內容﹝message body﹞，下 圖是通用訊息格式的ABNF。
generic-message = start-line
*message-header CRLF
[ message-body ]
start-line = request-Line | status-Line message-header = ﹝ general-header
| request-header | response-header | entity-header ﹞
a. 請求訊息﹝Request﹞
請求訊息的格式如下圖：
請求訊息的方法可分為：ACK、BYE、CANCEL、INVITE、OPTIONS、
REGISTER。當發話端欲初始一個通話連線，可傳送一個 INVITE 的 SIP 請求訊息；終止一個通話連線則可傳送一個 BYE 的 SIP 請求訊息：
下圖即為兩個端點之間的簡易呼叫流程範例：
n 呼叫流程說明
如上圖所示，發話端A 欲透過兩個代理伺服器(Proxy1 和 Proxy2) 向使用者B 要求建立通話連線，Proxy1 的進行訊息轉傳前需要使 用者進行認證手續，但發話端A 起初並未將認證資訊(F1)存放在訊 息之中，因此代理伺服器回傳一個認證需求的回應訊息通知發話端 進行下次的認證步驟(F2)。當發話端 A 再次傳送含有認證資訊的邀 請訊息後(F4)，使用者 B 接受該通話請求並開始進行通話，而後，
當使用者B 傳送 BYE 請求訊息之後，通話連線便結束。
Request = Request-Line
*﹝ general-header | request-header | entity-header ﹞ CRLF
[ message-body ]
² F1 - INVITE A -> Proxy 1
通話連線的開始是透過某個端點傳送INVITE 請求訊息，其訊 息內容如下圖所示，在這個訊息傳遞流程的範例中，要求訊息 內容包括了會議描述請求(Session Description Request)。
² F2 - 407 Proxy Authorization Required Proxy 1 -> User A SIP 協定是以請求―回應模式進行訊息的傳遞，在這個範例 中，Proxy1 要求發話端 A 需先進行認證步驟。
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP here.com:5060
From: BigGuy To: LittleGuy
Call-ID: [email protected] CSeq: 1 INVITE
Contact: BigGuy
Content-Type: application/sdp Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP
c=IN IP4 100.101.102.103 t=0 0
m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
SIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/UDP here.com:5060
From: BigGuy To: LittleGuy
Call-ID: [email protected] CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="MCI WorldCom SIP",
domain="wcom.com",
nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="", stale="FALSE", algorithm="MD5"
² F17 ACK Proxy2 -> UserB
當我們察看呼叫流程的下方，可發現實際的聲音串流傳送是以 Realtime Transport Protocol(RTP)處理。
² F18 BYE UserB -> Proxy2
通話連線是透過傳送BYE 請求給接收端終止。
ACK sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP ss2.wcom.com:5060 Via: SIP/2.0/UDP ss1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 From: BigGuy
To: LittleGuy ;tag=314159 Call-ID: [email protected] CSeq: 1 ACK
Content-Length: 0
BYE sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP there.com:5060 Route: ,
From: LittleGuy ;tag=314159 To: BigGuy
Call-ID: [email protected] CSeq: 1 BYE
Content-Length: 0
b. 回應訊息﹝Response﹞
其狀態碼依受話端的情況可分為：
n
1xx: Informational
表示伺服器或代理伺服器正在處理某些動作而且尚未有任何確 切的回應。
n
2xx: Success
請求成功而且必須終止該搜尋。
n
3xx: Redirection
提供使用者的新位址或其他能滿足該請求的服務。 界之規格標準，實作方面是採用JAIN(Java Application Integrated
Network)計劃中的 SIP 協定堆疊架構，其中 JAIN 這個組織主要的負責的工 作在於制定各種通訊協定(特別是網路電話方面的協定)的呼叫介面，讓各廠 商能依照其規定的呼叫流程實作其下的動作。本專題在這個部分則是依照該 呼叫介面將實作的功能完成，以銜接上層的端點協定(Peer Protocol)。
JAIN APIs 是一系列以 Java 虛擬機器為平台的網路通訊技術，以該技 術為基礎平台所發展的應用程式從網路連線或存取資料便能擁有足夠的可 攜性、完整性以及安全性。
JAIN 提供了抽象與關聯性的介面，可在公眾交換電話網路﹝Public Switched Telephone Network – PSTN﹞、封包交換網路 ﹝例如 Internet Protocol﹝IP﹞或 Asynchronous Transfer Mode﹝ATM﹞﹞和無線網路之 間建立服務元件，這便是所謂的整合式網路，除此之外，允許Java 應用程 式在安全的網路裡存取資源的優勢在於能夠同時提供各種功能不相同服務 元件。因此，相較於其他以單一網路架構為基礎的封閉式系統，JAIN 技術
Response = Status-Line
*﹝ general-header | response-header | entity-header ﹞ CRLF
[ message-body ]
JAIN 技術是 Java 平台的一種延伸，它的發展是在昇陽公司的 Java Specification Participation Agreement﹝JSPA﹞、Java Community ProcessSM﹝JCP﹞和 Community Source Code Licensing﹝SCSL﹞規範 下進行的，進一步的資訊可連接至http://jcp.org 參考。
JAIN 的發展提案包括兩種 API 規格類型：
1. 協定 API 規格定義了有線、無線與 IP 協定訊息。
2. 應用程式 API 規格訂定了以協定 API 規格為基礎架構的服務元件建立。
該套件依照Session Initiation Protocol(SIP) - RFC2543 的通訊協定 規格制訂了一套完整的訊息呼叫流程。下圖為SIP 的事件處理模型：
JAIN SIP API Specification 的模組套件名稱可依功能分為：
n jain.protocol.ip.sip
定義該套件中的核心元件：SipStack、SipProvider、ListeningPoint。
SipStack 功能在於建立、摧毀和管理其下所屬的 SipProvider 物件，
SipProvider 和 ListeningPoint 為一對一的關係，每個 SipProvider 僅擁有單一ListeningPoint，該類別負責解析接收到的協定訊息並將 事件(SipEvent)傳至上層聆聽者(SipListener)。
n jain.protocol.ip.sip.address
負責SIP 通訊協定的定址，包括三種定址格式：URI、SipURL、
NameAddress。
n jain.protocol.ip.sip.header
定義SIP 通訊協定訊息的各類型標頭資訊，依照其功能可分為：
General、Request、Response 和 Entity Header，而其建立方式需透 過HeaderFactory 來執行。
n jain.protocol.ip.sip.message
定義SIP 通訊協定的請求(Request)和回應(Response)訊息，依照兩 種協定訊息的特性可放入特定功能的標頭資訊，例如請求訊息可包括 General、Request 和 Entity Header；回應訊息可包括 General、
Response 和 Entity Header，其詳細規格可參考 RFC2543。
在本專題實作JAIN-SIP 規格介面期間，發現到以上幾種功能上的缺 失，造成上層建立其物件時會造成不易於使用的問題，以下幾點為這個版 本所無法支援的問題及本專題提供的解決方案：
1. 協定規格僅支援 RFC2543，而未支援目前最新的 RFC3261 本專題實作規格之版本編號是JAIN/SIP 1.0，儘管目前已公 佈最新的規格JAIN/SIP 1.1，但是當時專案正在實作期間，因此無 法及時更新至這個版本。另外，因為本專題主要的功能在於端點間 的訊息傳遞，並沒有建立通話連線的需求，所以使用的請求方法類 型為其後提出的MESSAGE，而舊有版本中並未定義此方法，因此 本專題特定為此加入該訊息類型，並遵循RFC3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging 的規範 實作簡短訊息的傳遞。
2. 不提供訊息交易層(Transaction)架構的功能
3. 對於 SipStack、SipProvider 的建立無法依所需設定其運作方式 因為這個版本的標準規格在建立以上兩種物件時並無法設定
TransactionManager
getId() : long
getInstance() : TransactionManager getProvider() : SipProvider getTransaction() : Transaction removeTransaction() : Transaction getClientTransaction() : ClientTransaction getServerTransaction() : ServerTransaction createClientTransaction() : ClientTransaction createServerTransaction() : ServerTransaction
Transaction
isServer() : boolean getId() : long
getManager() : TransactionManager getRequest() : Request
getResponse() : Response getConnection() : Connection setConnection() : void sendBye() : void doBYE() : void
ClientTransaction
sendAck() : void sendAck) : void sendAck() : void sendCancel() : void sendRequest() : void receiveResponse() : void
ServerTransaction
sendResponse() : void sendResponse() : void sendResponse() : void sendResponse() : void doAck() : void doCancel() : void receiveRequest() : void