頭域值可以以比較長(cháng)的格式或者壓縮格式出現在同樣的消息體中。在使用時(shí)每個(gè)頭都必須支持比較長(cháng)的格式和壓縮格式。

　　除非另外提示，Requests（請求）可能包括消息體，這種請求包括一個(gè)新請求，新請求在本規范的新拓展中定義。消息體解析依賴(lài)于請求方式method。

　　對響應消息來(lái)說(shuō)，請求方式和響應狀態(tài)碼決定消息體類(lèi)型和消息解析。所有的響應可能包括在一個(gè)消息體。

　　消息體的網(wǎng)絡(luò )媒體類(lèi)型必須通過(guò)Content-Type頭給定。如果消息體已經(jīng)處理過(guò)編碼流程，例如壓縮，那么必須通過(guò)Content-Encoding頭聲明；否則，必須忽略Content-Encoding。如果可行的話(huà)，聲明消息體字符串為Content-Type頭的一個(gè)部分。

　　在RFC 2046[11]定義的 "multipart" MIME 類(lèi)型可以在消息體中使用。在使用中，如果遠端部署方請求通過(guò)了一個(gè)Accept頭，這個(gè)頭沒(méi)有包含multipart，那么，發(fā)送的請求中包含多方消息體必須發(fā)送一個(gè)會(huì )話(huà)描述作為一個(gè)非multipart消息體。

　　SIP消息可以包含二進(jìn)制消息體或消息體的部分。當發(fā)送方?jīng)]有提供明確的字符參數設置時(shí)，被定義的text的媒體子類(lèi)型有一個(gè)默認字符設置值"UTF-8"。

　　以bytes為單位的消息體長(cháng)度是由Content-Length頭提供。Section 20.14描述了頭內容的具體細節。

　　HTTP/1.1中的分塊傳輸編碼不能在SIP中使用。（注意：為了以一系列的傳輸來(lái)分塊數據，分塊傳輸編碼修改了消息體，每一個(gè)塊都有各自的大小指示）

　　不像HTTP，SIP部署使用了UDP或其他的不可信賴(lài)的數據包協(xié)議。每個(gè)數據包傳輸一個(gè)請求或者響應。Section 18介紹了使用非可靠性傳輸的限定。

　　通過(guò)以數據流方式傳輸方式來(lái)處理SIP消息的機制必須在start-line之前忽略掉任何回車(chē)換行字符[H4.1]。

　　Content-Lengthheader頭的值用來(lái)定位數據流中的每個(gè)SIP消息結束位置。當SIP消息是通過(guò)數據方式傳輸時(shí)，它總是出現在這里。

　　一個(gè)用戶(hù)代理表示一個(gè)最終的系統架構。它包含一個(gè)用戶(hù)代理客戶(hù)端（UAC），用來(lái)產(chǎn)生請求，和一個(gè)用戶(hù)代理服務(wù)器端，它用來(lái)對請求產(chǎn)生響應反饋。UAC用戶(hù)代理客戶(hù)端具備產(chǎn)生請求的能力，UAC產(chǎn)生請求是由外部刺激和驅動(dòng)的流程而產(chǎn)生（例如，用戶(hù)點(diǎn)擊了一個(gè)按鈕和PSTN線(xiàn)路上的一個(gè)信號），并且對響應進(jìn)行處理。一個(gè)UAS代理客戶(hù)端可以接收一個(gè)請求，并且基于用戶(hù)輸入，外部驅動(dòng)刺激，程序執行結果或者其他機制所產(chǎn)生一個(gè)響應。

　　當一個(gè)UAC發(fā)送一個(gè)請求時(shí)，這個(gè)請求會(huì )經(jīng)過(guò)幾個(gè)代理服務(wù)器，這些代理服務(wù)器將前轉這個(gè)請求到UAS。當UAS生成響應時(shí)，這個(gè)響應會(huì )返回到UAC。

　　UAC和UAS的處理流程完全依賴(lài)于兩個(gè)因素。首先，這個(gè)流程取決于這個(gè)請求或響應是否在dialog里面還是外面，其次，流程還取決于請求的method。Dialogs的討論將會(huì )在Section 12進(jìn)行；它們表示一種介于用戶(hù)代理之間的點(diǎn)對點(diǎn)的關(guān)系，這個(gè)關(guān)系是通過(guò)具體的SIP methods創(chuàng )建的，例如INVITE。

　　在本部分內容中，我們討論UAC和UAS的執行處理規則，這個(gè)規則是完全獨立于method的，當處理請求時(shí)，這些請求是在dialog的外面。這里當然也包括請求自己創(chuàng )建的dialog。

　　關(guān)于dialog外部的對請求和響應的安全處理流程的描述在Section 26進(jìn)行。具體來(lái)說(shuō)，介于UAS和UAC存在的機制是互相驗證的過(guò)程。通過(guò)消息體使用S/MIME加密的方式實(shí)現一系列私有功能支持。

　　這部分討論UAC的外面dialog的運行狀態(tài)。

　　一個(gè)有效的被UAC規范化的SIP請求必須最低包括以下幾個(gè)頭字段：To，From， CSeq，Call-ID，Max-Forwards，和 Via；對所有SIP請求來(lái)說(shuō)，這些頭字段是強制支持的。

　　這六個(gè)頭字段是構建一個(gè)SIP消息的基礎結構，因為它們聯(lián)合起來(lái)為SIP通過(guò)了最基本

　　的和最重要的路由服務(wù)，消息地址，響應路由，限定消息擴展，消息順序和事務(wù)的唯一身份。

　　這些頭字段另外包含了method，Request-URI，和SIPversion。

　　運行在dialog外面的請求發(fā)送示例包括了一個(gè)INVITE，它用來(lái)創(chuàng )建一個(gè)會(huì )話(huà) （Section 13） 和一個(gè)OPTIONS，它用來(lái)查詢(xún)能力支持（Section 11）。

　　消息的初始Request-URI應該在To頭中設置為URL的值。一個(gè)需要注意的例外就是 REGISTER method；REGISTER 的Request-URI設置方式在Section 10中討論。對于安全原因或便利性來(lái)說(shuō)，它可能也不是太方便來(lái)設置這些值域為同樣的值（特別是，

　　如果在轉換期間，初始的UA希望Request-URI可以被修改的環(huán)境中）。

　　在某些特定的環(huán)境中，一個(gè)已存在的route狀態(tài)可以影響Request-URI的消息。一個(gè)已存在的路由系列是一系列有序URIs，這些URLs確認服務(wù)器鏈，UAC將會(huì )發(fā)送出去的請求，這些請求是dialog外部的請求。通常情況下，這些URL在UA端通過(guò)一個(gè)用戶(hù)或服務(wù)商手動(dòng)配置，或者通過(guò)其他的非SIP機制來(lái)配置。當服務(wù)商希望配置UA支持一個(gè)outbound proxy時(shí)，規范還是推薦需要提供一個(gè)已存在的路由系列，設置為一個(gè)單URI作為一個(gè) outbound proxy。