【正文】 eadervalue *(COMMA headervalue) 如上所示， SIP 頭字段允許一個頭字段可以定義多個參數(shù)值，且多個參數(shù)值之間用“ ,”字符進行分隔。 頭字段格式 SIP 消息的頭字段格式遵循 RFC2822 第 節(jié)所定義的通用頭字段格式定義規(guī)則。 fieldname: fieldvalue 如本規(guī)范第 25 節(jié)定義，消息頭字段中允許出現(xiàn)多個空格字符。依照以上規(guī)則，以下兩個頭字段是相同的。re there, pick up the phone and talk to me! Subject: I know you39。相同頭字段名的排列順序也非常重要，本規(guī)范規(guī)定，當且僅當字段值為多個字段值列表且字段值列表遵循 節(jié)定義的語法規(guī)則即多個字段值之間用“，”分割時，則一個消息內(nèi)允許同時存在多個相同的字段名行。 WWWAuthenticate、 Authorization、ProxyAuthenticate 和 ProxyAuthorization 字段不能遵循以上規(guī)則。 具體實現(xiàn)過程中，消息接收實體應按照同樣的規(guī)則處理字段名相同的多個字段行或一個包含字段列表的組合字段行。 1） Route: sip: Subject: Lunch Route: sip: Route: sip: 2） Route: sip:, sip: Route: sip: Subject: Lunch 3） Subject: Lunch Route: sip:, sip:, YD — 4 sip: 以下幾個例子符合消息定義規(guī)則，但彼此并不等價。通常頭字段名由 UTF8 字符集所包含的文本字符組成。多數(shù)頭字段名和頭字段屬性值之間用“ :”進行分隔，且頭字段中還可包含參數(shù)名和參數(shù)值，格式如下所示： fieldname: fieldvalue *(。 本協(xié)議規(guī)定，頭字段名對大小寫字符不敏感，即相同字段名不區(qū)分大小寫字符。例如，以下頭字段分別相同： 1) Contact: sip:。ExPiReS=3600 2) ContentDisposition: session。HANDLING=OPTIONAL 以下頭字段則不同： 3） Warning: 370 devnull Choose a bigger pipe Warning: 370 devnull CHOOSE A BIGGER PIPE 頭字段分類 SIP 消息某些頭字段僅當存在于請求或響應中的時候才有意義。當消息頭字段出現(xiàn)了不匹配的字段類型，則消息接收實體應忽略該字段，有關(guān)字段類型分類參見本規(guī)范第 20 章。壓縮格式參加本規(guī)范第 20 章。本協(xié)議規(guī)定同一頭字段名可出現(xiàn)在壓縮頭部或非壓縮頭部中，在具體實現(xiàn)過程中，消息接收實體應能識別并正 確處理這兩種不同格式的消息。對于 SIP 響應消息，請求方法和響應狀態(tài)碼可以識別消息實體的類型。 YD — 5 消息實體類型 消息實體的類型必須由“ ContentType”字段進行定義，且如果消息實體采用了壓縮編碼方式，則相應地應在“ ContentEncoding”字段中定義其所采用的壓縮編碼算法。在具體應用過程中，消息接收實體應將消息實體的內(nèi)容作為“ ContentType”頭字段值來對待。具體實現(xiàn)中，當請求發(fā)送方需要發(fā)送消息實體部分包含 MIME 信息單元的請求消息時，且消息接收方在“ Accept ”頭字段指示其不能接受 MIME 消息實體，則消息請求發(fā)送方應在消息中附加一個 SDP 部分作為非 MIME 消息實體進行發(fā)送。如果未明確指出，本規(guī)范中缺省的消息文本編碼類型是 UTF8。有關(guān)“ ContentLength”頭字段參見本規(guī)范第 節(jié)。在“ chunked”傳送編碼機制中，每一塊消息實體的長度由相應的標識符進行標識。關(guān)于 SIP 協(xié) 議以不可靠協(xié)議傳送有關(guān)要求參見本規(guī)范第 18 章。 “ ContentLength ”頭字段值用于定義一個 SIP 消息在流中的結(jié)束位置。 4 用戶代理 (UA)的基本行為 用戶代理 (UA)表 示 一個終端系統(tǒng)。 UAC 可以 根據(jù) 某些 外部 激勵 產(chǎn)生請求 消息 并且處理這些請求的 響應 消息。UAS 能夠 接收請求 消息 并產(chǎn)生響應 消息。而 UAS 產(chǎn)生一個響應 后 ，響應 消息 會以同樣的方式被轉(zhuǎn)發(fā)到 UAC。 對 話是 一種 UA 之間 的端到端對等 關(guān)系， 它 由特定的 SIP 消息 ， 如 INVITE 消息 建立。 對話之外的請求或響 應消息的安全性處理參見本規(guī)范第 26 章。 消息體可以 通過 S/MIME 進行加密。 請求消息的產(chǎn)生 本規(guī)范規(guī)定，由 UAC 產(chǎn)生的一個有效的 SIP 請求消息必須至少包含下列頭字段： To、 From、 CSeq、YD — 6 CallID、 MaxForwards 和 Via 頭字段，它們在所有的 SIP 請求消息都是必選的。另外，請求行（ request line）也是必選的，它包含了請求方法、 RequestURI、 SIP 版本信息。 RequestURI 除 REGISTER 請求，本協(xié)議中所有的請求消息的初始 RequestURI 都應被設為 To 頭字段中的 URI值。另外，出于安全 性考慮， UA 有時可能不希望將這兩個頭字段設為同樣的值，尤其是當發(fā)端 UA知道 RequestURI 可能會在傳輸中改變。預設路由集是一個有序的 URI 集合，它標識了一個服務器鏈， UAC 向這個服務器鏈發(fā)出對話外請求消息。本規(guī)范建議，在給某個 UA 配置一個外撥代理服務器時服務供應商所提供的預設路由集中只有一個 URI，即外撥代理服務器的 URI。 To 頭字段 To 頭字段指定請求消息的邏輯接收者或者是用戶或資源的注冊地址，該地址同樣是作為請求消息的目標地址。它可能包含一個 SIP 或 SIPS URI，或其它的 URI 方案（如 RFC2806 中的 tel URL）。 To 頭字 段中允許包含一個顯示名稱。通常經(jīng)過人機接口，由用戶輸入或者從地址簿中選取。如果這個字符串被用來構(gòu)造一個 SIP URI 的用戶部分，則用戶名稱在 符號右側(cè)所示的主域中被解析 ；如果這個字符串被用來構(gòu)造一個 SIPS URI 的用戶部分，則用戶希望進行安全的通信，同時用戶名將在 符號右側(cè)所示的主域中被解析 。此外，如果用戶輸入的是一個電話號碼，且UA 不會指定由某個主域來解釋該號碼，這時可以使用 tel URL，從而使請求消息所經(jīng)過的每一個主域都可以處理它。此時正確構(gòu)造的 URI 應該是“ tel:411”。對話之外的請求消息中不可以包含 To 標簽（ tag）。下例是一個有效的 To 頭字段： To： Carol sip： From 頭字段 From 頭字段是指示請求發(fā)起方的邏輯標識，它可能是用戶的注冊地址。 SIP 實體用它來決定如何處理一個請求（如呼叫自動拒絕）。 From 頭字段中允許包含一個顯示名稱。（如 sip:） 通常，某個 UA 產(chǎn)生的請求消息中的 From 頭字段值是由用戶或用戶本地主域的服務器預先設置的。請求消息的接收者要對發(fā)送者進行鑒權(quán)，以確認發(fā)送者身份與 From 頭字段相一致。 From 頭字段中必須包含一個新的由 UAC 選定的 “ tag”參數(shù)。例如： From: ”Bob” sips:。 tag=887s From: Anonymous sip:。本協(xié)議規(guī)定，在一個對話中， UA 發(fā)送的所有請求消息和響應消息都必須有同樣的 CallID。 當 UAC 產(chǎn)生一個新的對話外請求時，除非被某些方法指定，否則它必須為這個請求消息選擇一個在空間上和時間上都是全局唯一的 CallID 頭字段。當 UA 收到某些失敗的響應后，請求會根據(jù)響應的內(nèi)容修改并重發(fā)，這些重發(fā)的請求不作為新請求處理，因而也就不需要新的 CallID 頭字段。 具體實現(xiàn)可 采 用localidhost 的形式。 加密隨機標識符方法在一定程度上能防范黑客的會話攻擊，并降低了無意中產(chǎn)生 CallID 沖突的可能性。 關(guān)于 CallID 頭字段參見本規(guī)范 節(jié)。它由一個請求方法 和一個序列號組成，請求方法必須與對應的請求消息類型一致。但它必須可被表示成一個 32 位的無符號整數(shù)，且小于 231。 關(guān)于如何構(gòu)造在對話中發(fā)送的請求消息的 CSeq 頭字段參見本規(guī)范 節(jié)。它包含一個整數(shù)值，每經(jīng)過一跳，這 個值就被減一。 UAC 必須在它發(fā)起的每個請求中都插入 MaxFowords 頭字段，值為 70。 UA 只有知道網(wǎng)絡的拓撲結(jié)構(gòu)時，才可以謹慎地選擇更小的跳數(shù)值。只有當?shù)竭_下一 跳所用的傳輸協(xié)議被選定后，才能在請求消息中加入 Via 頭字段值。 Via 頭字段的協(xié)議名稱和協(xié)議版本必須分別為“ SIP”和“ ”。該參數(shù)既用在客戶端也用在服務器端。但有兩種情況例外：一是 CANCEL 請求，以后會說明 CANCEL 請求的 branch 參數(shù)與它所要取消的那個請 求的branch 參數(shù)是一樣的；另一個是對非 2xx 響應的 ACK 請求，參見本規(guī)范 節(jié)，這種情況下 ACK請求與相關(guān)的 INVITE 請求有著同樣的 branch ID，它所要確認的就是該 INVITE 的響應。 SIP 實體在插入 branch ID 時，必須以 ”z9hG4bK”開頭。另外， branch ID 參數(shù)的準確格式由具體的實現(xiàn)定義。 關(guān)于代理服務器對 Via 頭字段的處理參見本規(guī)范 節(jié)和 節(jié)。任何能夠建立對話的請求消息中都必須有 Contact 頭字段，并且該頭字段中只能含有一個 SIP 或 SIPS URI。對這些能建立對話的請求， Contact 的作用范圍是全局的。 如果請求消息的 RequestURI 或頂端 Route 頭字段值中包含了 SIPS URI，那么在 Contact 頭字段中也必須包含一個 SIPS URI。 Supported 和 Require 頭字段 如果 UAC 支持某些 SIP 協(xié)議的擴展，并且這些擴展可被服務器用來構(gòu)成請求的響應，那么 UAC應在請求消息中包含一個 Supported 頭字段，列出這些擴展的選項標簽。在實驗性和信息性 RFC 中定義的擴展禁止在 Supported 頭字段中使用。如果 UAC 希望在請求中使用某項擴展，并要求請求消息經(jīng)過的所有代理服務器都能理解 此擴展，它必須在請求消息中插入一個 ProxyRequire 頭字段，并列出此擴展的選項標簽。 消息的其它部分 在新的請求消息生成且上述頭字段被正確構(gòu)造之后，可加入任何其它的可選頭字段和請求方法所要求的特定頭字段。無論請求中包含的消息體類型如何，都必須構(gòu)造某些頭字段以表征消息體的內(nèi)容。 請求消息的發(fā)送 首先確定請求消息的發(fā)送目的地。其輸出結(jié)果是個可以發(fā) 送的目標地址有序集，其中每一項是個由地址、端口號以及傳輸協(xié)議構(gòu)成的三元組。 本地策略可指定其它目標地址集。此外，如果請求消息中不含 Route 頭字段，那么對該地址集中的地址沒有其它限制。但是，本規(guī)范建議用只含 單個 URI 的預設路由集來指定外撥代理服務器。只要 UA 確認這些服務器遵循本規(guī)范中對 Route 和 RequestURI 的處理策略。 這保證了那些不向請求消息中加入 RecordRoute 頭字段值的外撥代理服務器能從后續(xù)請求的傳輸路徑上離開。 對于有狀態(tài) SIP 實體， UAC 應當遵循 RFC3263 中定義的過程嘗試目標地址集中的每個地址，直到聯(lián)系上某個服務器。此外， Via 頭字段中的 transport 值也要根據(jù)不同的目標服務器來設置。經(jīng)事務層處理后再將其上傳給事務用戶（ TU）。 事務層錯誤 YD — 10 某些情況下，從事務層返回的并不是 SIP 消息，而是事務層錯誤消息。如果事務層報告的是嚴重錯誤，通常是UDP 方式下的嚴重 ICMP 錯誤或 TCP 連接失敗所致，則該消息的處理同 503（業(yè)務不可用）狀態(tài)碼。例如：如果 UAC 收到了一個無法識別的響應碼 431，那么它能 斷定自己發(fā)出的請求消息出錯，因而對該 431 碼的處理同 400（錯誤請求）響應碼。 UAC 必須能夠處理 100 和 183 響應。 在標識請求發(fā)起者的 Via 頭字段值之前出現(xiàn)了其它的 Via 頭字段值，表明消息在傳送過程中發(fā)生了路由錯誤，或者已被破壞。這同在 和 節(jié)中代理服務器遞歸處理 3xx 類響應的過程類似。如果客戶端要根據(jù)初始請求的一個 3xx類響應構(gòu)造新的請求消息，它應把可能的 URI 放入目標地址集中。同代理服務器進行遞歸處理時一樣，客戶端在處理 3xx 類響應時不可以將任何 URI 多次加入到目標地址集中。 任何新請求的發(fā)出都可能收到 3xx 響應，這些響應的又包含了原始請求的 RequestURI。所以為了防止出現(xiàn)重定向循環(huán)，規(guī)定任何 URI 只能在目標地址集中放置一次。通常是按 Contact頭字段值中 q 值的大小對地址集中的條目進行排序。一種做法是按 q值的降序分組后串行 處理，同組的 URI 并行處理。