SIP請求通過在起始行帶一個Request行和其他的method加以區(qū)別。一個請求行包含method名稱，一個Request-URI，和由單空格字符分開的協(xié)議版本。
請求行以換行符CRLF結束。可以允許無回車或換行，除了在以換行符結束的序列中。不允許在任何要素中有任意數量的空白格（LWS）存在。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method: 此規(guī)范定義了六個方法： REGISTER支持注冊聯(lián)系消息，INVITE，ACK， 和CANCEL支持會話創(chuàng)建，BYE支持結束會話，OPTIONS支持對服務器的能力查詢。SIP擴展中定義了其他的方法。
- Request-URI: Request-URI是一個SIP或SIP URL在Section 19.1 介紹，它或者是一個標準的URL（RFC 2396 [5]）。它表示這個用戶或這個服務被記錄。Request-URI不能包含非轉義符空格或控制字符，不能以"<>"方式出現(xiàn)。
- SIP 要素中可能支持Request-URIs，不一定是sip或者sips，也可能是其他的URL schemes形式，例如"tel"，這是RFC 2806 [9]的URL schemes。SIP要素可以在它們的處理過程中使用任何機制轉譯非SIP，最終生成SIP URI，或者其他的scheme。
- SIP-Version: 請求和響應都包括在使用的SIP版本，并且遵守 [H3.1]（HTTP替代了SIP，HTTP/1.1替代了SIP/2.0），這里涉及了版本順序，遵守要求和版本更新數量。 為了遵從此規(guī)范，應用程序發(fā)送到SIP消息必須包括SIP版本 "SIP/2.0"。 此SIP版本字符串是大小寫敏感，但是使用時必須發(fā)送大寫字母。
- 不像HTTP/1.1，SIP把此版本號看作為一個一般字面字符串。在實際使用時，這應該沒有什么不同。
7.2 Responses
SIP 響應消息和請求消息不同，響應消息包含一個Status-Line作為一個起始start-line。在每個要素中，一個Status-Line由響應版本，然后跟隨一個數字類型的狀態(tài)碼以及其關聯(lián)的文本短語，通過一個單空格字符分開。
除了在最后的CRLF順序中，可以允許無CR（回車）或者LF（換行）轉義字符。
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
狀態(tài)碼是一個三位整數的結果代碼，它表示一個測試輸出的響應理解，滿足請求的要求。原因短語的目的是對狀態(tài)碼給予一個短語解釋。使用狀態(tài)碼的目的是為了系統(tǒng)的自動處理，而原因短語的目的是方便用戶閱讀理解狀態(tài)原因，具有可閱讀性。用戶不要求檢查或顯示原因短語。
這里，此規(guī)范建議使用明確的用詞來表示原因短語，部署使用時可使用其他的文本。例如，在請求中的Accept-Language頭中的語言。
狀態(tài)碼的第一個數字定義了響應的級別。狀態(tài)碼后兩位沒有層級的設置。因為這個原因，任何狀態(tài)碼介于100和199之間的響應被看作是"1xx response"，任何狀態(tài)碼介于200和299的響應看作是一個"2xx response"響應，以此類推。以第一個數字為劃分類別，SIP/2.0支持了六個級別的狀態(tài)響應碼：- 1xx: Provisional – 請求收到的響應碼，表示是臨時響應，會繼續(xù)處理此請求；
- 2xx: Success – 成功收到處理流程，理解，接受了處理流程；
- 3xx: Redirection – 需要進一步的流程處理來完成此請求；
- 4xx: Client Error – 此請求中包含錯誤語法或不能滿足服務器的要求；
- 5xx: Server Error – 服務器端不能滿足一個明確有效請求；
- 6xx: Global Failure – 任何服務器都不能滿足此請求流程。
7.3 Header Fields
在語法和語義方面，SIP頭和HTTP頭非常相似。在實際應用環(huán)境中，SIP header 遵從[H4.2] 對消息頭的語法和對拓展頭的規(guī)則。但是，后者通過HTTP定義，使用了隱藏的空格。此規(guī)范和RFC 2234[10]是一致的，僅使用了明確的空格，并且看作為語法的一個部分。
[H4.2] 也定義了同一域名稱的多個頭的語法，這些值都以逗號隔離的列表，這些列表可以合并成一個頭值。這個應用方式也可以支持SIP，但是因為具體的規(guī)范有所不同。具體來說，任何SIP頭都以下語法的形式表現(xiàn)
header = "header-name" HCOLON header-value *（COMMA header-value）
可以支持合并同一名稱的頭成為一個逗號隔離的列表。此 Contact header支持逗號隔離的列表，除非這個頭的值是"*"。
7.3.1 Header Field Format
頭域遵從標準的頭格式標準，在Section 2.2 of RFC 2822 [3]定義。每個頭由域名，然后冒號（":"） 和域值構成。
field-name: field-value
消息頭頂標準語法在Section 25 定義，然后緊跟一個任意數量的空格。但是，在部署使用時應該避免基于頭域和冒號之間的空格，在值域和冒號之間使用一個單空格。
- Subject: lunch
- Subject : lunch
- Subject :lunch
- Subject: lunch
因此，以上格式都是有效的，建議使用最后的格式。
Header 頭域可以擴展為多行，實現(xiàn)方式是通過在每一行前添加至少一個SP或HT tab鍵來實現(xiàn)。在下一行開始前的換行符和空格被看作是一個單SP政府。因此，以下幾種格式表達的意思是相同的：
- Subject: I know you're there, pick up the phone and talk to me!
- Subject: I know you're there,
- pick up the phone
- and talk to me!
帶不同域值的頭的相對順序不是非常重要。但是，規(guī)范推薦，為了支持代理處理，這些頭（Via, Route，Record-Route，Proxy-Require，Max-Forwards，和Proxy-Authorization，例如） 應該出現(xiàn)在消息體的頂部來支持代理的快速解析。頭的相對順序和其對應的名稱是非常重要的。如果或只有如果那個頭的域值定義為以逗號分割的列表時（Section 7.3的多頭值域可能出現(xiàn)在消息中，但是，因為它們的語法沒有遵從Section 7.3的標準格式，它們不允許合并為單頭行域值。
使用時必須可以處理同樣名稱的多頭值，無論是每行單值合并的頭或是逗號分隔的方式。
以下各組頭值是有效，相等的：
- Route: <sip:alice@atlanta.com>
- Subject: Lunch
- Route: <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Subject: Lunch
- Subject: Lunch
- Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com>
每個組的值是有效的但是又表達各自不同含義：
- Route: <sip:alice@atlanta.com>
- Route: <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Route: <sip:bob@biloxi.com>
- Route: <sip:alice@atlanta.com>
- Route: <sip:carol@chicago.com>
- Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, <sip:bob@biloxi.com>
頭的名稱格式是通過每個頭名稱來定義的。它總是是UTF8文本八位字節(jié)不確定度順序出現(xiàn)或空格，標志符，分隔符和帶引號的字符出現(xiàn)。許多存在的頭會附加到通過標準規(guī)范值，通過分號的方式，分隔參數名稱，參數值，具體格式為：
field-name: field-value *（;parameter-name=parameter-value）
雖然任意數目的參數可以附加到頭上，但是，任何已給定的參數名稱不能出現(xiàn)第二次。
當對比頭值時，頭名稱總是大小寫不敏感的。要不然，這個頭是一個指定的頭，它已經聲明了值域名稱，參數名稱和參數值是大小寫不敏感的頭。標記符總是大小寫不敏感的字符。除非，這個標記符已經聲明其屬性，否則，被引號標注的字符值是大小寫敏感的值。例如，
Contact: <sip:alice@atlanta.com>;expires=3600
等同于
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
和
Content-Disposition: session;handling=optional
等同于
content-disposition: Session;HANDLING=OPTIONAL
以下這兩組是不相同的：
- Warning: 370 devnull "Choose a bigger pipe"
- Warning: 370 devnull "CHOOSE A BIGGER PIPE"
7.3.2 Header Field Classification
一些頭值僅使用在請求和響應的處理中，并且具有一定的意義。它們被稱之為request header fields 和 response header fields。如果一個頭出現(xiàn)在消息體中，沒有匹配任何頭的層級（例如，請求的頭出現(xiàn)在響應的消息體中），它則必須被忽略掉。Section 20定義了頭的各種層級。
關注微信公眾號：asterisk-cn，獲得有價值的IP通信行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
