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

　　Content-Lengthheader頭的值用來定位數(shù)據(jù)流中的每個SIP消息結(jié)束位置。當(dāng)SIP消息是通過數(shù)據(jù)方式傳輸時，它總是出現(xiàn)在這里。

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

　　當(dāng)一個UAC發(fā)送一個請求時，這個請求會經(jīng)過幾個代理服務(wù)器，這些代理服務(wù)器將前轉(zhuǎn)這個請求到UAS。當(dāng)UAS生成響應(yīng)時，這個響應(yīng)會返回到UAC。

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

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

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

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

　　一個有效的被UAC規(guī)范化的SIP請求必須最低包括以下幾個頭字段：To，F(xiàn)rom， CSeq，Call-ID，Max-Forwards，和 Via；對所有SIP請求來說，這些頭字段是強(qiáng)制支持的。

　　這六個頭字段是構(gòu)建一個SIP消息的基礎(chǔ)結(jié)構(gòu)，因?yàn)樗鼈兟?lián)合起來為SIP通過了最基本

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

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

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

　　消息的初始Request-URI應(yīng)該在To頭中設(shè)置為URL的值。一個需要注意的例外就是 REGISTER method；REGISTER 的Request-URI設(shè)置方式在Section 10中討論。對于安全原因或便利性來說，它可能也不是太方便來設(shè)置這些值域?yàn)橥瑯拥闹担ㄌ貏e是，

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

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