SIP RFC 3261 中文文件（RFC3261） - 程式人生

SIP RFC 3261 中文文件（RFC3261）. 阿新• • 發佈：2019-02-04. 7、SIP訊息：. SIP協議是一個基於文字的協議，使用UTF-8字符集（RFC2279[7]）。

程式人生>>SIPRFC3261中文文件（RFC3261） SIPRFC3261中文文件（RFC3261） 阿新••發佈：2019-02-04 7、SIP訊息： SIP協議是一個基於文字的協議，使用UTF-8字符集（RFC2279[7]）。

一個SIP訊息既可以是一個從客戶端到伺服器端的請求，也可以是一個從伺服器端到客戶端的一個應答。

即使在字符集上和語法細節上有所不同，請求（7.1）還是應答（7.2）訊息都基於RFC2822格式的。

（SIP允許包頭域不是標準的RFC2822包頭域）。

這兩種訊息型別都由一個起始行，一個或者多個包頭域，一個可選的訊息中文組成。

一般訊息＝                          起始行 *訊息包頭 CRLF [訊息正文] 起始行＝                                    請求行/狀態行 起始行、每一個包頭行，空行、都必須由回車換行組成（CRLF）。

即使訊息中文沒有，也必須有一個空行跟隨。

除了在字符集上的區別以外，很多SIP的訊息和包頭域的格式都同HTTP/1.1一樣。

我們在這裡就不重複它的語法和語義了，我們用[HX.Y]來標誌HTTP/1.1規範（RFC2616[8]）的X.Y節的描述。

SIP並非一個HTTP的超集或者擴充套件。

7．1 請求 SIP請求是根據起始行中的Request-Line來區分的。

一個Request_line包含方法名字，Request－URI，用單個空格（SP）間隔開的協議版本。

Request-Line由CRLF結束。

除了用作行結束標誌以外，不允許CR或者LF出現在其他地方。

在其他域中，不允許出現線形的空白（linerwhitespaceLWS） Request-Line                    =       MethodSPRequest-URISPSIP-VERSIONCRLF Method: 這個規範規定了6中方法：REGISTER用於登記聯絡資訊，INVITE，ACK,CANCEL用於建立會話，BYE用於結束會話，OPTIONS用於查詢伺服器負載。

SIP擴充套件、標準RFC追加可能包含擴充套件的方法。

Request-URI: Request-URI是一個SIP或者SIPSURI，他們在19.1節由描述。

也可以是一個通用的URI(RFC2396[5])。

它標誌了這個請求所用到的使用者或者服務的地址。

Request-URI禁止包含空白字元或者控制字元，並且禁止用”<>”括上。

SIP元素可以支援除了SIP或者SIPS之外所規定的Request-URIs。

比如”tel”URI模式（RFC2806[9]）。

SIP元素可以用他們自己的機制來轉換non-SIPURIs到SIPURI，SIPSURI或者其他什麼格式的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把版本號當作一個文字串處理。

在實現上，這個應該不會有區別。

7．2應答 SIP應答和SIP請求的區別在於在START-LINE中是否包含一個STATUS-LINE。

一個status-line在由數字表達的status－code之前，是一個協議的版本串，每一個元素之間用一個單個SP（空格）分開。

除了最後用作結束標誌以外，CR/LF不允許出現在其他地方。

status-line                         =SIP-VERSIONSPSTATUS-CODESPReasong-PhraseCRLF Status-Code是一個3位的數字resultcode，用來標誌處理請求的一個結果。

Reason-Phrase是一個簡短的Status-Code的說明。

Status-Code是為了能自動處理使用的，但是Reason-Phrase是用來給使用者看得。

一個客戶端並不要求一定要顯示或者解釋這個Reason-Phrase。

本文件建議輸出這個reason-phrase,實現中可以選擇其他文字，比如用請求包頭中指定的合適語言來顯示。

status－code的第一個數字表示了應答的型別。

接下來兩個數字並不作分類使用。

基於這個原因，任何statuscode在100到199的可以統稱位”1xx應答”，類似的，在200到299的可以統稱位”2xx應答”，依此類推。

SIP/2.0允許6類應答： 1xx：臨時應答－請求已經接收，正在處理這個請求。

2xx：成功處理－請求已經成功接收，並且正確處理了這個請求。

3xx：重定向－還需要附加的操作才能完成這個請求，本請求轉發到其他的伺服器上處理。

4xx：客戶端錯誤－－請求包含錯誤的格式或者不能在這個伺服器上完成。

5xx：伺服器錯誤－伺服器不能正確的處理這個顯然合法的請求。

6xx：全域性錯誤－請求不能被任何伺服器處理。

21節定義了詳細的程式碼說明。

7.3 頭域 SIP頭域和HTTP頭域在語法和語義上都比較類似。

特別的，SIP頭域遵循[H4.2]關於訊息頭的語法的定義，並且遵循多行的擴充套件頭域的規則。

(後者isspecifiedinHTTPwithimplicitwhitespaceandfolding)。

這個規範遵循RFC2234[10]，並且把清晰的空白和封裝作為內在的語法規則。

[H4.2]也定義了具有相同域名的多個頭域，他們的值是用逗號分開的列表，可以合併到一個頭域中。

這個也適用於SIP，但是細節上略有不同，因為語法不同。

實際上，任何SIP的包頭語法都是基於如下正規化的： header＝“header-name”HCOLONheader-value*(COMMAheader-value) 這個允許合併在具有同一個域名的多個頭域，到一個用逗號分割的單個頭域中。

Contact頭域除了當域值是”*”之外，都允許用逗號分割的列表。

7.3.1頭域格式。

頭域遵循在RFC2822的2.2節定義的通用頭域格式。

每一個頭域都由一個域名加上冒號（”:”）和域值組成。

                                          field-name:field-value 訊息頭的正則語法在25節中有介紹介紹。

在訊息頭中，允許在冒號的左右有任意個數的空白；但是，在實現中，建議避免域名和冒號中間有空格，並且建議在冒號和值之間使用單個空格（SP）。

                                          Subject:         lunch                                           Subject    :     lunch                                           Subject         :lunch                                           Subject:lunch 所以，上面的都是合法的，也是相等的，但是最後一種是我們所推薦的。

頭域可以擴充套件成為多行的，只要在每一個附加行前邊用至少一個SP或者水平TAB(HT)打頭就可以了。

這種多行的頭域在行結尾並且在下一行之前的空白SP（或者HT）將被認為是一個單個的SP字元。

所以，下邊的例子是相等的：                                           Subject: Iknowyou’rethere,pickupthephoneandtalktome!                                           Subject:Iknowyou’rethere,                                                  pickupthephone,                                                  andtalktome! 頭域中的不同域名的相關順序並沒有什麼意義。

雖然如此，我們還是強烈建議與路由相關的域（VIA,ROUTE,Record-Route,Proxy-Require,Max-Forwards,Proxy-Authorization等等）放在訊息頭的最前邊，這樣可以提高處理的速度。

相同域名的域之間的順序非常重要。

只有當單個頭域的域值是可以用逗號分割的列表的時候，才可以表達成為同一個域名的多個頭域（這就是說，如果遵循7.3定義的語法）。

也就是意味著必須可以將同一個域名的多個頭域在不改變訊息語義的前提下，改換表達成為一對”域名: 域值”；這個轉換是通過順序增加每一個域的域值，域值之間用逗號分割。

這個規則有幾個例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization頭域。

多個頭域行可以在訊息頭中出現，但是由於他們的語法並不遵循7.3中定義的通用格式，所以，他們並不能合併成為單個頭域行。

在實現上，必須能夠既能夠處理多個頭域行的情況，也必須能夠處理用逗號分割的合併的單個頭域行的情況。

下邊的幾組頭域是相等的：                                          Route:                                          Subject:Lunch                                          Route:                                          Route: Route:,                                          Route:                                          Subject:Lunch                                          Subject:Lunch                                          Route:,                                                   下邊各組是合法的，但是並不相等。

Route: Route: Route: Route: Route: Route: Route:,, 每一個頭域值的格式是依賴於它的頭域名的。

他可以是任意順序的TEXT-UTF8字元，也可以是一個空格，標記，分隔符，引號括起來的字串的組合。

很多頭域都回附帶一個通用的域值格式。

這個域值格式是由分號分開的引數名和引數值的組合：                                          field-name:field-value*(;parameter-name=parameter-value) 雖然在域值裡邊可以有任意數量的parameter-name/parameter-value對，但是不能允許有相同的parameter-name存在（唯一性）。

除了特別指出的頭域之外，頭域中的域名、域值、parameternameparameter-value都是大小寫不敏感的。

標記詞始終是大小寫不銘感的。

除非有特別的指定，引號串的字串是大小寫敏感的。

例如：                                          Contact:;expires=3600 和                                          CONTACT:;ExPiReS=3600 相同。

                                         Content-Disposition:session;handling=optional 和                                          content-disposition:Session;HANDLING=OPTIONAL 相同。

下邊的兩個頭域不相同：                                          Warning:370devnull“Chooseabiggerpipe”                                          Warning:370devnull“CHOOSEABIGGERPIPE” 7.3.2頭域分類。

有一些頭域是僅僅在請求（或者應答）中有效的。

這些頭域叫做請求頭域或者應答頭域。

如果訊息中的頭域與這個訊息的型別不匹配（比如在應答訊息中出現的請求頭域），這個頭域必須被忽略。

20節定義了每一個頭域的分類。

7.3.3縮寫格式 SIP提供了一個用縮寫格式來表達通用頭域名字的機制。

這個有助於避免訊息過大而導致通訊層無法傳輸（比如在UDP傳輸的時候超過了最大傳輸單元(MTU)）。

這個縮寫格式在20節定義。

縮寫格式的訊息頭域名字可以在不改變訊息語義的情況下替代較大的訊息頭域名字。

在單個訊息中，頭域名字既可以用長的格式，也可以用縮寫格式。

在實現中，必須同時支援對長名字和縮寫名字的處理。

7.4包體 請求資訊，包括這個規範以後的擴充套件的新請求，都可以包含一個訊息正文體。

對訊息正文體的解釋依賴域請求的方法（請求型別）。

對於應答訊息來說，請求方法和應答狀態（responsestatuscode）決定了訊息正文體的格式。

所有的應答訊息都可以有一個訊息正文體（body）。

7.4.1訊息正文型別(MessageBodyType) 訊息中的internet媒體類別必須在Content-Type頭域中指明。

如果訊息正文（body）通過某種形式的編碼（encoding），比如壓縮等等，都必須在Content-Encoding頭域中指明，否則Content-Encoding域必須忽略。

如果可行，訊息體的字符集作為Content-type頭域的值的一部分表達。

在RFC2046[11]中定義的多部分”multipart”MIME型別可以在訊息體中應用。

在由多部分組成的訊息體傳送的時候，如果接受方的實現中，包頭域的Accept域中，不包含多部分的標記，那麼傳送方必須傳送一個非多部分的sessiondescription。

SIP訊息可以包含二進位制的包體或者部分包體。

如果傳送方沒有其他顯示的字符集引數指出，媒體的文字”text”子型別會是預設的字符集”UTF-8”。

7.4.2訊息體長度 在Content-Length頭域中存放了包體的位元組長度。

第20.14節講述了本域的詳細解釋。

HTTP/1.1的“chunked”傳輸編碼方式並不適用於SIP。

（備註：chuncked編碼傳輸方式是通過把訊息正文體分為一系列的塊來傳輸的，每一塊有它自己的大小標記） 7.5 分幀的SIP訊息（FramingSIPMessages） 不同於HTTP的是，SIP實現可以使用UDP或者其他非可靠傳輸協議。

每一幀包括一個請求或者應答。

第18節講述了非可靠傳輸的應用。

在處理以面向流的通訊為基礎的SIP訊息的時候，必須忽略在開始行之前的CRLF[H4.1]。

Content-Length頭域用來確定每一個SIP訊息在通訊流中的結束位置的。

在基於面向流通訊基礎上的SIP訊息一定要使用這個頭域。

 Implementationsthatsendrequests containingmultipartmessagebodiesMUSTsendasessiondescription asanon-multipartmessagebodyiftheremoteimplementationrequests thisthroughanAcceptheaderfieldthatdoesnotcontainmultipart. . FastDFSJava客戶端配置 «上一篇 AngularJS分割重組字串下一篇» 相關推薦 SIPRFC3261中文文件（RFC3261） 7、SIP訊息： SIP協議是一個基於文字的協議，使用UTF-8字符集（RFC2279[7]）。

一個SIP訊息既可以是一... Mybatis框架中Mapper文件傳值參數獲取。

【Mybatis】 ramkeywordddrgemcliviewaticopytooneMybatis框架中，Mapper文... python一個包中的文件調用另外一個包文件實例 patdefpreimgendimporttestimpclaspython不同文件夾中模塊的引用調用順序... Java中的文件上傳和下載 獲取httpsres文件內容ttytype()valname表單文件上傳原理： 　　早期的文件上傳機制： ... [轉]Qt中ui文件的使用 如何pro進行rect相關setutf8產生pan用designer設計的*.ui文件可以通過uic工具轉... iOS中.pch文件怎樣使用 watercsdn例如popups老版本texcontentdata- pch能夠用來存儲共享信息，... ORACLE因為字符集不同，進行中文條件查詢，查詢結果為空 查詢數據服務spancodeoracl字符串客戶notnulllec在使用C#進行SQL語言或者ASP.... Python中的文件類型 com編譯-obspenvblog程序pyo類型Python文件類型有3種：源代碼文件、編譯文件、優化文件... 程序中的文件之沙盒以及plist文件的初步使用 iceb2cng-可見ngs函數用戶nsdatanss 沙盒是相對於“應用程序”的文件，也就是相相應ap... python中對文件的處理 and刪除eva改密名稱賬號字典oat行為1.當文件中存放的用戶名的密碼,是以字符串的形式存儲時，怎麽進行... 搜尋 基礎教學 Mysql入門 Sql入門 Android入門 Docker入門 Go語言入門 Ruby程式入門 Python入門 Python進階 Django入門 Python爬蟲入門 最近訪問