sip 協議是乙個基於文字的協議，使用 utf-8 字符集（rfc2279[7]）。乙個 sip 訊息既可以是乙個從客戶端到伺服器端的請求，也可以是乙個從伺服器端到客戶端的乙個應答。
訊息型別都由乙個起始行，乙個或者多個包頭域，乙個可選的訊息中文組成。
起始行、每乙個包頭行，空行、都必須由回車換行組成（crlf）。即使訊息正文沒有，也必須有乙個空行跟隨。
sip 請求是根據起始行中的 request-line 來區分的。乙個 request_line 包含方法名字，request－uri，用單個空格（sp）間隔開的協議版本。
request-line 由 crlf 結束。除了用作行結束標誌以外，不允許 cr 或者 lf 出現在其他地方。在其他域中，不允許出現線形的空白（liner whitespace lws）
request-line = method sp request-uri sp sip-version crlfrequest-uri: request-uri 是乙個 sip 或者 sips uri。也可以是乙個通用的 uri(rfc 2396[5])。它標誌了這個請求所用到的使用者或者服務的位址。request-uri 禁止包含空白字元或者控制字元，並且禁止用」<>」括上。也可以是乙個通用的 uri(rfc 2396[5])。它標誌了這個請求所用到的使用者或者服務的位址。request-uri 禁止包含空白字元或者控制字元，並且禁止用」<>」括上。
sip 元素可以支援除了 sip 或者 sips 之外所規定的 request-uris。比如」tel」 uri 模式（rfc 2806[9]）。sip 元素可以用他們自己的機制來轉換 non-sip uris 到 sip uri，sips uri 或者其他什麼格式的 uri。
sip-version：請求和應答訊息都包含當前使用的 sip 版本，這個遵循[h3.1](類 似 http 用 sip 替代，用 sip/2.0 替代 http/1.1)中關於版本的規定，版本依賴，公升級版本號。乙個應用，發出的 sip 訊息一定包含了 sip-version 「sip/2.0」。這個 sip 版本串是大小寫不敏感的，但是在實現中必須傳送大寫。不像 http/1.1,sip 把版本號當作乙個文字串處理。在實現上，這個應該不會有區別。
sip 應答和 sip 請求的區別在於在 start-line 中是否包含乙個 statusline。乙個 status-line 在由數字表達的 status－code 之前，是乙個協議的版本串，每乙個元素之間用乙個單個 sp（空格）分開。
除了最後用作結束標誌以外，cr/lf 不允許出現在其他地方。
status-line = sip-version sp status-code sp reasong-phrase crlfstatus－code 的第乙個數字表示了應答的型別。接下來兩個數字並不作分類使用。基於這個原因，任何 status code 在 100 到 199 的可以統稱位」1xx 應答」，類似的，在 200 到 299 的可以統稱位」2xx 應答」，依此類推。sip/2.0 允 許 6 類應答：
sip 頭域和 http 頭域在語法和語義上都比較類似。任何 sip 的包頭語法都是基於如下正規化的：
header ＝ 「 header-name」 hcolon header-value *(comma headervalue)每乙個頭域都由乙個網域名稱加上冒號（」:」）和域值組成。
field-name:field-value所以，上面的都是合法的，也是相等的，但是最後一種是我們所推薦的。頭域可以擴充套件成為多行的，只要在每乙個附加行前邊用至少乙個 sp 或者水平tab(ht)打頭就可以了。這種多行的頭域在行結尾並且在下一行之前的空白 sp（或者 ht）將被認為是乙個單個的 sp 字元。所以，下邊的例子是相等的：
頭域中的不同網域名稱的相關順序並沒有什麼意義。但建議與路由相關的域（via,route,record-route,proxy-require,maxforwards,proxy-authorization 等等）放在訊息頭的最前邊，這樣可以提高處理的速度。相同網域名稱的域之間的順序非常重要。只有當單個頭域的域值是可以用逗號分割的列表的時候，才可以表達成為同乙個網域名稱的多個頭域。也就是意味著必須可以將同乙個網域名稱的多個頭域在不改變訊息語義的前提下，改換表達成為一對」網域名稱: 域值」；這個轉換是通過順序增加每乙個域的域值，域值之間用逗號分割。這個規則有幾個例外，就是 wwwauthenticate, authorization, proxy-authenticate,和 proxy-authorization39頭域。多個頭域行可以在訊息頭**現，但是由於他們的語法並不遵循上面定義的通用格式，所以，他們並不能合併成為單個頭域行
在實現上，必須能夠既能夠處理多個頭域行的情況，也必須能夠處理用逗號分割的
合併的單個頭域行的情況。下邊的幾組頭域是相等的：
下邊各組是合法的，但是並不相等。
每乙個頭域值的格式是依賴於它的頭網域名稱的。他可以是任意順序的 text-utf8字元，也可以是乙個空格，標記，分隔符，引號括起來的字串的組合。很多頭域都回附帶乙個通用的域值格式。這個域值格式是由分號分開的引數名和引數值的組：
合：
field-name: field-value *(;parameter-name=parameter-value)請求資訊，包括這個規範以後的擴充套件的新請求，都可以包含乙個訊息正文體。對訊息正文體的解釋依賴域請求的方法（請求型別）。對於應答訊息來說，請求方法和應答狀態（response status code）決定了訊息正文體的格式。所有的應答訊息都可以有乙個訊息正文體（body）。
訊息中的 internet **類別必須在 content-type 頭域中指明。如果訊息正文（body）通過某種形式的編碼（encoding），比如壓縮等等，都必須在content-encoding 頭域中指明，否則 content-encoding 域必須忽略。如果可行，訊息體的字符集作為 content-type 頭域的值的一部分表達。
在rfc2046[11]中定義的多部分」multipart」 mime型別可以在訊息體中應用。在由多部分組成的訊息體傳送的時候，如果接受方的實現中，包頭域的accept域42
中，不包含多部分的標記，那麼傳送方必須傳送乙個非多部分的session description。
sip 訊息可以包含二進位制的包體或者部分包體。如果傳送方沒有其他顯示的字符集
引數指出，**的文字」text」子型別會是預設的字符集」utf-8」。
在 content-length 頭域中存放了包體的位元組長度。
http/1.1 的「chunked」傳輸編碼方式並不適用於 sip。（備註：chuncked 編碼傳輸方式是通過把訊息正文體分為一系列的塊來傳輸的，每一塊有它自己的大小標記）
不同於 http 的是，sip 實現可以使用 udp 或者其他非可靠傳輸協議。每一幀包括乙個請求或者應答。
在處理以面向流的通訊為基礎的 sip 訊息的時候，必須忽略在開始行之前的crlf[h4.1]。content-length 頭域用來確定每乙個 sip 訊息在通訊流中的結束位置的。在基於面向流通信基礎上的 sip 訊息一定要使用這個頭域。
SIP訊息格式
sip 訊息格式 首行 start line 請求行 響應 狀態行 請求行 1.方法 invite,cancel,ack,bye 用於會話的建立 修改和終止 register 用於對使用者的聯絡資訊進行註冊 options 用於對伺服器及其能力進行查詢 2.請求 url 用來標識所請求資源的 sip...
SIP協議詳解
sip 協議概念 會話啟動協議sip session initiation protocol 是乙個在ip網路上進行多 通訊的應用層控制協議，它被用來創 建 修改 和終結乙個或多個參加者參加的會話程序。sip協議可用於發起會話，也可以用於邀請成員加入已經用其它方式建立的會話。sip協議透明地支援名字...
SIP協議初探
1.sip協議的定義 2.sip協議特點 位於應用層，作用 主要控制通訊雙方的信令。h.323和sip分別是通訊領域與網際網路兩大陣營推出的協議。h.323企圖把ip 當作是眾所周知的傳統 只是傳輸方式發生了改變，由電路交換變成了分組交換。而sip協議側重於將ip 作為網際網路上的乙個應用，較其它應...