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