SIP（Session Initiation Protocol）會話啟動協議

SIP（Session Initiation Protocol）會話啟動協議是一個面向於網路電話和會議的的應用程式層的控制（信令）協議。主要是一個基於IP網路的多媒體通訊協議。它能實現的信令功能也都利用RTP作為媒體傳輸的協議。最初由IETF MMUSIC (Multiparty Multimedia Session Control) 工作群組提出。

SIP能實現的功能主要有：1，網路辦公；2，即時短訊息；3，即時狀態管理；4，網路的IP電話；5，網路會議。有以下幾部分組成，
底層： UA Toolkit API(工具包）
介面層：呼叫控制(API)，使用者狀態管理(API)，立即訊息(API)
應用程式層：
UAC(用戶端)流程
呼叫控制-〉初始化（包括註冊）-〉會話呼叫建立-〉媒體與資料通道的協商-〉SDP資料包的解析
使用者狀態-〉狀態資訊的訂閱和通知-〉狀態資訊的設定-〉狀態資訊的查詢
立即訊息 傳送立即訊息：接收立即訊息
UAS(伺服器端)
會議管理：建立會議，加入會議，修改會議，離開通話，結束會議，會議相關資訊的查詢，公布會議狀態；
使用者管理：位置資訊查詢，使用者認證，增加使用者，刪除使用者；
媒體管理：初始化（協商媒體通道，指定連接埠和屬性），發送媒體流，接收媒體流，使用者增加或刪除媒體流。
提供RTP/RTCP協議棧完成媒體流的發送/接收和傳輸。

 在串連的地址上採用的是url的，比較方便，格式主要為：使用者名稱＠主機地址、被叫號碼＠PSTN網關地址和如Tel：010-62281234這樣普通電話號碼的描述等。SIP的最強大之處就是使用者定位功能。訊息和信令均採用文本編碼。SIP用於發起一個會話，控制管理多個參與者參與的多媒體會話，並且動態調整會話的屬性。SIP獨立於低層協議，一般使用UDP等不需連線的協議，而採用自己的應用程式層可靠性機制來保證訊息的可靠傳輸。

重要概念：
UA：使用者代理程式 描述一個普通的使用者終端和使用者代理程式，SIP中有客戶機和伺服器之分。客戶機是指為了向伺服器發送請求而與伺服器建立連線應用程式程式。使用者代理程式（User Agent）和代理（Proxy）中含有客戶機。伺服器是用於向客戶機發來的請求提供服務並回送應答的應用程式。共有4類基本伺服器：
· 使用者代理程式伺服器：當接到SIP請求時聯絡使用者，並代表使用者返迴響應。
· Proxy 伺服器：代表其他客戶機發起請求，既充當伺服器又充當客戶機的媒介程式。它在轉寄請求之前可能改寫原請求訊息中的內容。
· 重新導向伺服器：接收SIP請求，把請求中的原地址映射成零個或多個新地址，返回給客戶機。
· 註冊伺服器：接收客戶機的註冊請求，完成使用者地址的註冊。

 SIP對以文本形式表示的訊息的詞法和文法分析就比較簡單。具有分布式的組播功能。
提供的功能： 1）名字翻譯和使用者定位： 2）特徵協商： 3）呼叫參與者管理 4）呼叫特徵改變
SIP中有兩個要素：SIP使用者代理程式和SIP網路伺服器。
使用者代理程式是呼叫的終端系統元素，而SIP伺服器是處理與多個呼叫相關聯信令的網路裝置。使用者代理程式本身具有一客戶機元素（使用者代理程式客戶機UAC）和一伺服器元素（使用者代理程式伺服器UAS）。客戶機元素初始呼叫而伺服器元素應答呼叫。這允許點到點的呼叫通過客戶機-伺服器協議來完成。
SIP伺服器的主要功能是提供名字解析和使用者定位。可以獲得的是email形式的地址或與被來電者關聯的電話號碼。使用該資訊，呼叫者的使用者代理程式能夠確定特定伺服器來解析地址資訊--這可能涉及網路中很多伺服器。 SIPProxy 伺服器接收請求，決定將這些請求傳送到何處，並且將它們傳送到下一伺服器（使用下一跳路由原理）。在網路中可以有多跳。

SIP協議棧的結構：
SIP的最底層是文法和編碼。
第二層是傳輸層：它定義了網路上一個客戶機如何發送請求和接收響應以及一個伺服器如何接收請求和發送響應。
第三層是事務層：事務層處理應用程式層重傳，匹配響應到請求，以及應用程式層逾時。
任何使用者代理程式客戶機（UAC）完成的任務使用一組事務產生。 SIP通過EMAIL形式的地址來標明使用者地址。每一使用者通過一等級化的URL來標識，它通過諸如使用者電話號碼或主機名稱等元素來構造（例如：SIP:user@company.com）。因為它與EMAIL地址的相似性，SIP URLs容易於使用者的EMAIL地址關聯。 呼叫者用INVITE請求初始呼叫當一使用者希望呼叫另一使用者，呼叫者用INVITE請求初始呼叫，請求包含足夠的資訊用以被來電者參與會話。如果客戶機知道另一方的位置它能夠直接將請求發送到另一方的IP地址。如果不知道，客戶機將請求發送到本地配置的SIP網路伺服器。如果伺服器是Proxy 伺服器它將解析被呼叫使用者的位置並且將請求發送給它們。有很多方法完成上步，例如搜尋DNS或訪問資料庫。伺服器也可以是重新導向伺服器，它可以返回被呼叫使用者的位置到呼叫客戶機用以它直接與使用者聯絡。在定位使用者的過程中，SIP網路伺服器當然能夠代理或重新導向呼叫到其它的伺服器，直到到達一個明確地知道被呼叫使用者IP地址的伺服器。一旦發現使用者地址，請求就發送給該使用者，此時將產生幾種選擇。在最簡單的情況，使用者電話客戶機接收請求——也就是，使用者的電話響鈴。如果使用者接受呼叫，客戶機用客戶機軟體的指定能力響應請求並且建立串連。如果使用者拒絕呼叫，會話將被重新導向到語音郵箱伺服器或另一使用者。"指定能力"參照使用者想啟用的功能。例如，客戶機軟體可以可使用視訊會議，但使用者只想使用音訊會議，那則只會啟用音頻功能。
SIP還具有另外兩個有重要意義的特徵。第一個是有狀態SIPProxy 伺服器具有分割入呼叫或複製入呼叫的能力，從而可以同時運行幾個擴充分支。第一個應答的分支接受呼叫。該特徵在使用者工作在兩位置之間（例如實驗室和辦公室）或者同時對經理和其秘書響鈴時是非常便利的。第二個特徵是SIP獨特的返回不同媒體類型的能力。舉個使用者聯絡公司的例子。當SIP伺服器接收到客戶機的串連請求，它能夠通過WEB互動式語音響應頁面來返回到顧客的客戶機，該頁面具有可獲得的部門分支或提供在列表上的使用者。點擊適當的連結後將發送一請求到所點擊選擇的使用者從而建立起呼叫。

有兩種類型的SIP訊息：
● 請求：從客戶機發到伺服器
● 響應：從伺服器發到客戶機
SIP請求訊息包含三個元素：請求行、頭、訊息體。 SIP響應訊息包含三個元素：狀態行、頭、訊息體。 請求行和頭域根據業務、地址和協議特徵定義了呼叫的本質，訊息體獨立於SIP協議並且可包含任何內容。

SIP定義了下述方法：
INVITE——邀請使用者加入呼叫。
BYE——終止一呼叫上的兩個使用者之間的呼叫。
OPTIONS——請求關於伺服器能力的資訊。
ACK——確認客戶機已經接收到對INVITE的最終響應。
REGISTER——提供位址解析的映射，讓伺服器知道其它使用者的位置。
INFO——用於會話中信令。

2.1 SIP訊息的總體描述
SIP訊息有兩種：客戶機到伺服器的請求（Request）,伺服器到客戶機的響應（Response）。 SIP訊息由一個起始行（start-line）、一個或多個欄位（field）組成的訊息頭、一個標誌訊息頭結束的空行（CRLF）以及作為可選項的訊息體（message boby）組成，其中描述訊息體（message body）的頭稱為實體頭（entity header）。 generic-message = start-line *message-header CRLF [message-body] 起始行分請求行（Request-Line）和狀態行（Status-Line）兩種，其中請求行是請求訊息的起始行，狀態行是響應訊息的起始行。訊息頭分通用頭（general-header）,要求標頭(request-header),回應標頭（response-header）和實體頭（entity-header）四種。

2.2 SIP請求訊息請求訊息的格式如下。
Request = Request-Line *(general-header | request-header | entity-header CRLF [message-body] 請求行（Request-Line）以方法（method）標記開始，後面是Request-URI和協議版本（SIP-Version）,最後以斷行符號鍵結束，各個元素間用空格鍵字元間隔。 Request-Line = Method SP Request-URI SP SIP-Version CRLF SIP 用術語"method"來對說明部分作以描述，Method標識是區分大小寫。SIP定義了以下幾種方法（methods）。 Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "CANCEL" | "REGISTER" | "INFO" -INVITE INVITE方法用於邀請使用者和服務參加一個會話。在INVITE請求的訊息體中可對被叫方被邀請參加的會話作以描述。如主叫方能接收的媒體類型、發出的媒體類型及其一些參數：對INVITE請求的成功響應必須在響應的訊息體中說明被叫方願意接收那種媒體，或者說明被叫方發出的媒體。伺服器可以自動地用200（OK）響應會議邀請。 -ACK ACK請求用於客戶機向伺服器證實它已經收到了對INVITE請求的最終響應。ACK只和INVITE請求一起使用。對2xx最終響應的證實由客戶機使用者代理程式發出，對其它最終響應的證實由收到響應的第一個代理或第一個客戶機使用者代理程式發出。ACK請求的To、From、Call-ID,Cseq欄位的值由對應的INIVITE請求的相應欄位的值複製而來。 -OPTIONS 用於向伺服器查詢其能力。如果伺服器認為它能與使用者聯絡，則可用一個能力集響應OPTIONS請求；對於代理和重新導向伺服器只要轉寄此請求，不用顯示其能力。 OPTIONS的From、To分別包含主被叫的地址資訊，對OPTIONS請求的響應中的From、To(可能加上tag參數)、Call-ID欄位的值由OPTIONS請求中響應的欄位值複製得到BYE. 使用者代理程式客戶機用BYE請求向伺服器表明它想釋放呼叫。 BYE請求可以象INVITE請求那樣被轉寄，可由主叫方發出也可以由被叫方發出。呼叫的一方在釋放（掛斷）呼叫前必鬚髮出BYE請求，收到BYE請求的這方必須停止發媒體流給發出BYE請求的這方。 -CANCEL CANCEL請求用於取消一個Call-ID,TO,From和Cseq(僅序號)欄位值相同的進行中的請求，但取消不了已經完成的請求（如果伺服器返回一個最終狀態響應，則認為請求已完成）。 CANCEL請求中的Call-ID,To,Cseq的數字部分及From欄位和原請求的對應欄位值相同，從而使CANCEL請求與它要取消的請求匹配。 -REGISTER REGISTER 方法用於客戶機向SIP伺服器註冊列在To欄位中的地址資訊。 REGISTER 請求訊息頭中各個欄位的含義定義如下： To:含要建立或更新的註冊的地址記錄。 From:含提出註冊的人的地址記錄。 Request-URI:註冊請求的目的地址，地址的域部分的值即為主管註冊者所在的域，而主機部分必須為空白。一般，Request-URI中的地址的域部分的值和To中的地址的域部分的值相同。 Call-ID:用於標識特定客戶機的請求。來自同個客戶機的註冊請求至少在相同重啟周期內Call-ID欄位值應該相同；使用者可用不同Call-ID值註冊不同的地址，後面的註冊請求將替換前面的所以請求。 Cseq:Call-ID欄位值相同的註冊請求的Cseq欄位值必須是遞增的，但次序無關係，伺服器並不拒絕無序請求。 Contact:此欄位是可選：用於把以後發送到TO欄位中的URI的非-註冊請求轉到Contact欄位給出的位置那裡。如果請求中沒有Contact 欄位，那麼註冊保持不變。 Expires:表示註冊的截止期。 -INFO INFO 方法是對SIP協議的擴充，用於傳遞會話中產生的與會話相關的控制資訊，如：ISUP和ISDN信令訊息，有關此方法的使用還有待標準化，詳細內容參見IETF RFC 2976。

2.3 SIP響應資訊響應資訊的格式如下。
Response = Status-Line *(general-header | response-header | entity-header CRLF [message-body] 狀態行（Status-Line）以協議版本開始，接下來是用數字表示的狀態代碼（Status-Code）及相關的文本說明，最後以斷行符號鍵結束，各個元素間用空白字元（SP）間隔，除了在最後的CRLF序列中，這一行別的地方不允許使用斷行符號或換行字元。 Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF SIP協議中用三位整數的狀態代碼（Status Code）和原因值（Reason Code）來表示對請求的作出回答，狀態代碼用於機器識別操作，原因短語（Reason-Phrase）是對狀態代碼的簡單文字描述，用於人工識別操作。 Status-Code = 1xx (Information) | 2xx (Success) | 3xx (Redirection) | 4xx (Client-Error) | 5xx (Service-Error) | 6xx (Global-Failure) | extension-code 狀態代碼的第一個數字定義響應的類別，在SIP/2.0中第一個數字有6個值，定義如下： 1xx: informational － 請求已經收到、繼續處理請求。 2xx: success － 行動已經成功地收到，理解和介紹。 3xx: Redirection － 為完成呼叫請求，還須採取進一步地動作。 4xx: Client Error － 請求有語法錯誤或不能被伺服器執行。客戶機需修改請求，然後再重發請求。 5xx: Server Error － 伺服器出錯，不能執行合法請求。 6xx: GLOBAL FAILURE － 任何伺服器都不能執行請求。 其中 1xx 響應為暫時響應（Provisional response）,其它響應為最終響應（Final Response）。

2.4 SIP地訊息頭欄位
SIP協議的訊息定義與HTTP在文法規則和定義上很相似。每個頭欄位都遵循以下格式；首先是欄位名（Field Name）,欄位名不分大小寫，後面是冒號，然後是欄位值，欄位值與冒號間可有多個前置空格（LWS）。 message-header = field-name ":" [field-value] CRLF field-name = token field-value = * (field-content | LWS) （1）通用訊息頭（General-header）通用頭欄位適用於請求訊息和響應訊息，包含的欄位有： general-header = Accept | Accept-Encoding | Accept-Language | Call-ID | Contact | CSeq | Data | Encryption | Expires | From | Organization | Record-Route | Timestamp | To | User-Agent | Via 其中，Accept,Accept-Encoding,Accept-Language欄位用於客戶機在請求訊息中給出可接受的響應的媒體類型，編碼方式，以及描述語言：用於伺服器在415響應中表明其可理解的請求訊息的媒體類型，編碼方式，以及描述語言。 Call-ID欄位用於唯一標識特定邀請或某個客戶機的註冊請求，一個多媒體會議可產生多個Call-ID不同的呼叫。 Contact欄位給出一個URL,使用者可以與此URL建立進一步的通訊。 Cseq 欄位用於識別服務器發出的不同請求，若Call-ID值相同，那麼Cseq值必須各不相同。 Date 欄位反映首次發出請求或響應訊息的時間，重發的訊息與原先的訊息有相同的Data欄位值。 Encryption欄位表明內容經過了加密處理，這種加密為端到端的加密。 Expire欄位給出訊息內容截止的日期和時間。 所有訊息中都必須有From欄位，此欄位給出請求的發起者。 Organization欄位給出發出請求或響應訊息的實體所屬的組織名稱。 Record-Route欄位給出一個全域可到達的Request-URI,用於標識Proxy 伺服器。 Time-Stamp欄位給出客戶機向伺服器發出請求的時間。 所有訊息中都必須有To欄位，此欄位給出請求的目的收方。 User-Agent 欄位含有與發起請求的使用者代理程式客戶機有關的資訊。 Via欄位給出請求訊息迄今為止經過的路徑。（2）Entity-header 實體頭欄位用於定義與訊息體相關的資訊。 Entity-header = Content-Encoding | Content-Length | Content-Type Content-Encoding欄位表明訊息體上添加應用的內容編碼方式。 Content-Length 欄位表明訊息體的大小。 Content-Type欄位表明訊息體的媒體類型。 （3）Request-header 要求標頭欄位用於客戶機上傳附加資訊到伺服器，其中包括有關請求和客戶機本身的資訊。 request-header = Authorization | Contact ; | Hide ; | Max-Forwards ; | Priority ; | Proxy-Authorization ; | Proxy-Require ; | Route ; | Require ; | Response-Key ; | Subject ; Authorization欄位用於使用者代理程式向伺服器評鑑自身身份。 Hide 欄位用於客戶機表明其希望向後面的Proxy 伺服器或使用者代理程式隱藏由Via欄位構成的路徑。 Max-Forwords欄位表明請求訊息允許被轉寄的次數。 Priority欄位用於客戶機表明請求的緊急程度。 Priority-Authorization欄位用於客戶機向要求省份認證的Proxy 伺服器表明自身身份。 Proxy-Require 欄位用於標識出代理必須支援的代理敏感特徵。 Route 欄位決定請求訊息的路由。 Require欄位用於客戶機告訴Proxy 伺服器為了正確讓伺服器處理請求，客戶機希望伺服器支援的選項。 Require-Key 欄位用於給出被叫方使用者代理程式加密響應訊息所採用的密鑰需滿足的要求。 Subject 欄位提供對呼叫的概述或表明呼叫的性質，可用於呼叫過濾。（4）Response-header 回應標頭欄位用於伺服器向Request-URI指定的地址傳送有關響應的附加資訊。 response-header = Allow | Proxy-Authenticate | Retry-After | Server | Unsupported | Warning | WWW-Authenticate Proxy-Authenticate 欄位必須為407響應的一部分，欄位中的值給出適用於Request-URI的代理的認證體制和參數。 Retry-After欄位可用於503響應中，向發出請求的客戶機表明服務預計多久以後可以啟用，用於404，600，603響應中表明被叫何時再有空。 Server 欄位含有使用者代理程式伺服器處理請求所使用的軟體資訊。 Unsupported欄位列出伺服器不支援的特徵。 Warning欄位用於傳遞與響應狀態有關的附加資訊。 www-Authenticate欄位含於401響應中，指出適用於Request-URI的認證體制和參數。