国产精品久久久久久网站,国产综合一区二区

　　7.1 Requests

　　SIP請求通過在起始行帶一個Request行和其他的method加以區(qū)別。一個請求行包含method名稱，一個Request-URI，和由單空格字符分開的協(xié)議版本。

　　請求行以換行符CRLF結(jié)束。可以允許無回車或換行，除了在以換行符結(jié)束的序列中。不允許在任何要素中有任意數(shù)量的空白格（LWS）存在。

　　Request-Line = Method SP Request-URI SP SIP-Version CRLF

　　Method: 此規(guī)范定義了六個方法： REGISTER支持注冊聯(lián)系消息，INVITE，ACK，和CANCEL支持會話創(chuàng)建，BYE支持結(jié)束會話，OPTIONS支持對服務(wù)器的能力查詢。SIP擴(kuò)展中定義了其他的方法。

Request-URI: Request-URI是一個SIP或SIP URL在Section 19.1 介紹，它或者是一個標(biāo)準(zhǔn)的URL（RFC 2396 [5]）。它表示這個用戶或這個服務(wù)被記錄。Request-URI不能包含非轉(zhuǎn)義符空格或控制字符，不能以"<>"方式出現(xiàn)。
SIP 要素中可能支持Request-URIs，不一定是sip或者sips，也可能是其他的URL schemes形式，例如"tel"，這是RFC 2806 [9]的URL schemes。SIP要素可以在它們的處理過程中使用任何機(jī)制轉(zhuǎn)譯非SIP，最終生成SIP URI，或者其他的scheme。
SIP-Version: 請求和響應(yīng)都包括在使用的SIP版本，并且遵守 [H3.1]（HTTP替代了SIP，HTTP/1.1替代了SIP/2.0），這里涉及了版本順序，遵守要求和版本更新數(shù)量。為了遵從此規(guī)范，應(yīng)用程序發(fā)送到SIP消息必須包括SIP版本 "SIP/2.0"。此SIP版本字符串是大小寫敏感，但是使用時必須發(fā)送大寫字母。
不像HTTP/1.1，SIP把此版本號看作為一個一般字面字符串。在實(shí)際使用時，這應(yīng)該沒有什么不同。

　　7.2 Responses

　　SIP 響應(yīng)消息和請求消息不同，響應(yīng)消息包含一個Status-Line作為一個起始start-line。在每個要素中，一個Status-Line由響應(yīng)版本，然后跟隨一個數(shù)字類型的狀態(tài)碼以及其關(guān)聯(lián)的文本短語，通過一個單空格字符分開。

　　除了在最后的CRLF順序中，可以允許無CR（回車）或者LF（換行）轉(zhuǎn)義字符。

　　Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

　　狀態(tài)碼是一個三位整數(shù)的結(jié)果代碼，它表示一個測試輸出的響應(yīng)理解，滿足請求的要求。原因短語的目的是對狀態(tài)碼給予一個短語解釋。使用狀態(tài)碼的目的是為了系統(tǒng)的自動處理，而原因短語的目的是方便用戶閱讀理解狀態(tài)原因，具有可閱讀性。用戶不要求檢查或顯示原因短語。

　　這里，此規(guī)范建議使用明確的用詞來表示原因短語，部署使用時可使用其他的文本。例如，在請求中的Accept-Language頭中的語言。

　　狀態(tài)碼的第一個數(shù)字定義了響應(yīng)的級別。狀態(tài)碼后兩位沒有層級的設(shè)置。因?yàn)檫@個原因，任何狀態(tài)碼介于100和199之間的響應(yīng)被看作是"1xx response"，任何狀態(tài)碼介于200和299的響應(yīng)看作是一個"2xx response"響應(yīng)，以此類推。以第一個數(shù)字為劃分類別，SIP/2.0支持了六個級別的狀態(tài)響應(yīng)碼：

1xx: Provisional – 請求收到的響應(yīng)碼，表示是臨時響應(yīng)，會繼續(xù)處理此請求；
2xx: Success – 成功收到處理流程，理解，接受了處理流程；
3xx: Redirection – 需要進(jìn)一步的流程處理來完成此請求；
4xx: Client Error – 此請求中包含錯誤語法或不能滿足服務(wù)器的要求；
5xx: Server Error – 服務(wù)器端不能滿足一個明確有效請求；
6xx: Global Failure – 任何服務(wù)器都不能滿足此請求流程。

　　Section 21 定義了這些級別和描述了其無效碼。

　　7.3 Header Fields

　　在語法和語義方面，SIP頭和HTTP頭非常相似。在實(shí)際應(yīng)用環(huán)境中，SIP header 遵從[H4.2] 對消息頭的語法和對拓展頭的規(guī)則。但是，后者通過HTTP定義，使用了隱藏的空格。此規(guī)范和RFC 2234[10]是一致的，僅使用了明確的空格，并且看作為語法的一個部分。

　　[H4.2] 也定義了同一域名稱的多個頭的語法，這些值都以逗號隔離的列表，這些列表可以合并成一個頭值。這個應(yīng)用方式也可以支持SIP，但是因?yàn)榫唧w的規(guī)范有所不同。具體來說，任何SIP頭都以下語法的形式表現(xiàn)

　　header = "header-name" HCOLON header-value *（COMMA header-value）

　　可以支持合并同一名稱的頭成為一個逗號隔離的列表。此 Contact header支持逗號隔離的列表，除非這個頭的值是"*"。

　　7.3.1 Header Field Format

　　頭域遵從標(biāo)準(zhǔn)的頭格式標(biāo)準(zhǔn)，在Section 2.2 of RFC 2822 [3]定義。每個頭由域名，然后冒號（":"）和域值構(gòu)成。

　　field-name: field-value

　　消息頭頂標(biāo)準(zhǔn)語法在Section 25 定義，然后緊跟一個任意數(shù)量的空格。但是，在部署使用時應(yīng)該避免基于頭域和冒號之間的空格，在值域和冒號之間使用一個單空格。

Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch

　　因此，以上格式都是有效的，建議使用最后的格式。

　　Header 頭域可以擴(kuò)展為多行，實(shí)現(xiàn)方式是通過在每一行前添加至少一個SP或HT tab鍵來實(shí)現(xiàn)。在下一行開始前的換行符和空格被看作是一個單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!

　　帶不同域值的頭的相對順序不是非常重要。但是，規(guī)范推薦，為了支持代理處理，這些頭（Via, Route，Record-Route，Proxy-Require，Max-Forwards，和Proxy-Authorization，例如）應(yīng)該出現(xiàn)在消息體的頂部來支持代理的快速解析。頭的相對順序和其對應(yīng)的名稱是非常重要的。如果或只有如果那個頭的域值定義為以逗號分割的列表時（Section 7.3的多頭值域可能出現(xiàn)在消息中，但是，因?yàn)樗鼈兊恼Z法沒有遵從Section 7.3的標(biāo)準(zhǔn)格式，它們不允許合并為單頭行域值。

　　使用時必須可以處理同樣名稱的多頭值，無論是每行單值合并的頭或是逗號分隔的方式。

　　以下各組頭值是有效，相等的：

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>

　　每個組的值是有效的但是又表達(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>

　　頭的名稱格式是通過每個頭名稱來定義的。它總是是UTF8文本八位字節(jié)不確定度順序出現(xiàn)或空格，標(biāo)志符，分隔符和帶引號的字符出現(xiàn)。許多存在的頭會附加到通過標(biāo)準(zhǔn)規(guī)范值，通過分號的方式，分隔參數(shù)名稱，參數(shù)值，具體格式為：

　　field-name: field-value *（;parameter-name=parameter-value）

　　雖然任意數(shù)目的參數(shù)可以附加到頭上，但是，任何已給定的參數(shù)名稱不能出現(xiàn)第二次。

　　當(dāng)對比頭值時，頭名稱總是大小寫不敏感的。要不然，這個頭是一個指定的頭，它已經(jīng)聲明了值域名稱，參數(shù)名稱和參數(shù)值是大小寫不敏感的頭。標(biāo)記符總是大小寫不敏感的字符。除非，這個標(biāo)記符已經(jīng)聲明其屬性，否則，被引號標(biāo)注的字符值是大小寫敏感的值。例如，

　　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

　　一些頭值僅使用在請求和響應(yīng)的處理中，并且具有一定的意義。它們被稱之為request header fields 和 response header fields。如果一個頭出現(xiàn)在消息體中，沒有匹配任何頭的層級（例如，請求的頭出現(xiàn)在響應(yīng)的消息體中），它則必須被忽略掉。Section 20定義了頭的各種層級。