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