【正文】 是通過把消息正文體分為一系列的塊來傳輸?shù)?，每一塊有它自己的大小標記） 分幀的SIP消息（Framing SIP Messages）不同于HTTP的是，SIP實現(xiàn)可以使用UDP或者其他非可靠傳輸協(xié)議。每一幀包括一個請求或者應答。第18節(jié)講述了非可靠傳輸?shù)膽谩Ｔ谔幚硪悦嫦蛄鞯耐ㄓ崬榛A的SIP消息的時候，必須忽略在開始行之前的CRLF[]。ContentLength頭域用來確定每一個SIP消息在通訊流中的結(jié)束位置的。在基于面向流通訊基礎上的SIP消息一定要使用這個頭域。8 一般用戶代理行為一個用戶代理代表了一個終端系統(tǒng)。它包含一個用戶代理客戶端（UAC）,用來產(chǎn)生請求的，它包含一個用戶代理服務端（UAS），用來響應請求的。UAC可以由一些外部的東西來發(fā)
出請求和處理應答（比如用戶按了一個按鈕，或者按下了一個電話鍵產(chǎn)生了一個音頻信號等等）。UAS是一個能夠接收請求，并且產(chǎn)生應答的東西，它可以根據(jù)用戶輸入，外部輸入
，程序執(zhí)行結(jié)果或者其他什么機制來產(chǎn)生應答。當一個UAC發(fā)送一個請求，這些請求可能通過一些PROXY（代理服務器）傳遞到UAS上。當UAS產(chǎn)生一個應答，那么這個應答就會同樣的被傳送到UAC。UAC和UAS的處理由兩個特點。第
一，基于請求或者應答是否在一個對話里，第二，基于請求的方法（method）。會話的徹底描述在第12節(jié)；哪里描述了點對點的用戶代理之間的關(guān)系，并且通過一些SIP方法建立了
會話，比如INVITE方法等。在本節(jié)，我們將討論在處理對話外的請求時，UAC和UAS的方法無關(guān)的規(guī)則。這些當然也包括用于建立會話的請求。在26節(jié)講述了對在對話外的請求和應答的安全處理。特別時，UAS
和UAC之間的互相認證的機制。通過用S/MIME加密的消息體可以提供有限的隱私保證。 UAC特性本節(jié)講述UAC在會話外的特性。 產(chǎn)生一個請求一個合法的SIP請求必須至少包含如下頭域：TO,FROM,Cseq,CallID,MaxForwards, Via。這些字段在所有SIP請求中必須包含。這6個字段是SIP消息的基本組成部分，他們提供了用
于路由用的核心信息，包含了消息的地址，響應的路由，消息傳遞次數(shù)，詳細的順序，事務的唯一標志。這些頭域字段是必須包含在請求行之后的，請求行包含了請求的方法，RequestURI,SIP的版本號碼。有兩個在對話外的發(fā)送請求的示例（通過INVITE請求建立連接，第13節(jié)），（通過OPTIONS請求查詢負載，第11節(jié)）。 RequestURI最開始的RequestURI頭域應該是TO頭域的的值。但是在REGISTER方法中，有一個值得注意的不同；REGISTER方法的RequestURI頭域在第10節(jié)中指出。出于隱私的原因而把這些字
段的值設置成為同一個值并不太合適（尤其是如果初始的UA期望RequestURI會在傳輸中改變的話）。在一些特定的情況下，預先設置的路由表（routeset）會影響消息中的RequestURI。一個預置路由表是由一串server的URI組成，這些服務器是UAC往外發(fā)送會話外請求所需要經(jīng)
過的。通常，他們是由用戶或者服務提供商手工在UA上設置的，或者通過一些非SIP的方法自動設置。當一個提供商希望配置一個出口proxy給一個UA，我們強烈建議通過一個預置
一個單個URI路由表的方式來實現(xiàn)，這個單個路由就是出口proxy。當要使用預置路由表(route set)，必須提供RequestURI和Route頭域（）（甚至在沒有對話存在的時候也必須提供），并且把RequestURI當作遠端目
標URI。 TOTo頭域是第一個并且也是最先指定請求的”邏輯”接收地，或者是這個請求的用戶或者資源的addressofrecord。這個域內(nèi)的地址可以是也可以不是請求的最終接收者。TO頭域可
以用SIP或者SIPS URI,也可以用其他方式的URI(比如電話URL (RFC2806[9]))。所有的SIP實現(xiàn)必須支持SIP URI的實現(xiàn)。任何支持TLS的實現(xiàn)必須支持SIPS URI的實現(xiàn)。To頭域允許有一個顯示用的姓名。UAC可以通過無數(shù)的方法來知道在一個給定請求的時候該如何填寫TO頭域。通常用戶會建議采用人工界面中輸入的To頭域，可能手工輸入這個URI或者從地址本中選擇（就好像
outlook郵件中的to一樣）。用戶通常不會輸入完整的URI,可能只是一個簡單的字串（比如”bob”）。這就要求UA能夠判斷用戶輸入的這個到底是那個URI。一般使用用戶輸入的字
串加上”@”標志和主機的名字組合成為SIP URI(比如sip:bob@)。如果希望通訊在保密機制下進行，那么就用用戶輸入的字串組成SIPS URI的部分，用戶輸入的將加上
”@”和主機的名字作為整個SIPS URI。這個主機的名字通常是請求方的主機名字，這個主機允許處理外發(fā)請求。這個很像”縮位撥號”的機制，這個機制要求請求者自身的主機能
夠解釋這個縮位撥號一樣。如果UA不希望指定主機，那么就需要將用戶輸入的電話號碼解釋成為一個電話的URL。相當于，每一個請求經(jīng)過的主機都會有機會來處理這個請求。比如，一個用戶在機場可能登陸
機場的代理服務器，并且通過機場的代理服務器發(fā)出一個請求。如果他輸入”411”(美國本地電話本查詢服務號碼)，這個就需要機場的外發(fā)的代理服務器進行解釋和處理，而不是
解釋成有主機的用戶。在這里，tel:411是一個正確的解釋。在會話外的請求中，不能包含To tag字段，在to頭域中的tag是用來在對話中做標志的。既然對話還沒有建立，那么tag就不能存在。下邊這個例子是一個To頭域的例子：To: Carol sip:carol@ FromFrom頭域包含了請求發(fā)起者的邏輯標志，可能是用戶的addressofrecord。就像To頭域一樣，F(xiàn)rom頭域也包含一個URI并且可以包含一個顯示的姓名。SIP可以用這個頭域來實現(xiàn)對
請求的檢查和選擇一個規(guī)則進行對請求的處理（比如，自動的呼叫拒絕，凡是x人發(fā)過來的東西，一律無視）。同樣的，因為From頭域包含的是邏輯名字，所以From URI也可以不包
含IP地址或者UA對應的主機名字FQDN。From頭域可以包含一個顯示姓名。在客戶身份隱藏的情況下，一個UAC應該使用顯示名字”Anonymous”，連通一個語法正確，但是沒有意義的URI(比如：
sip:thisis@)。通常，用戶或者用戶的本地主機的管理人員會事先規(guī)定請求頭域中的From頭域的值。如果給定的UA是多個用戶共同使用的，那么必須有一個URI
對應身份的profile，這樣才能夠切用戶的profile。收到請求的服務方可以根據(jù)這個用于分辯身份的URI來區(qū)分同一個UA上的不同的用戶，并且根據(jù)他們的From頭域來判定他們的身
份。（22節(jié)有更多的驗證說明）。From域必須包含一個由UAC產(chǎn)生的新的”tag”參數(shù)。例子：From: “Bob” sips:bob@ 。 tag=a48sFrom: sip:+12125551212@。tag=887sFrom: Anonymous sip:c8oqz84zk7z@。tag=hyh8 CallIDCallID是一個在一系列消息中，區(qū)分一組消息的唯一標志。在對話中的任一UA的所有請求和所有應答的CallID必須一致。在UA的每次注冊中，都應該是一樣的。在會話外的時候
，UAC發(fā)起一個新的請求，這個CallID頭域必須由UAC產(chǎn)生一個全局（在時間和空間上都是）唯一的CallID, 除非是請求頭的方法（method）指明了別的產(chǎn)生方式。所有的SIP UA
都必須保證自己產(chǎn)生的CallID不會和其他UA產(chǎn)生的CallID重復。注意，如果是請求的重新嘗試，則重新嘗試的請求不被當作一個新的請求，所以不需要新的CallID（重新嘗試的
請求例如：認證沖突等等）。（）我們強烈建議用密碼亂序隨機串（RFC 1750[12]）來產(chǎn)生CallID。實現(xiàn)中，可以用類似”localid@host”這樣的格式產(chǎn)生。CallID是大小寫敏感的，并且通過簡單字節(jié)/字節(jié)的來
進行比較。采用密碼亂序隨機串可以降低會話被竊聽的機會，并且降低CallID重復的沖突。不規(guī)定或者要求使用用戶界面來選擇輸入CallID頭域的值。例子：CallID: f81d4fae7dec11d0a76500a0c91e6bf6@ CseqCseq 頭域是用來區(qū)分和做位事務的順序使用的。他由一個方法（method）和一系列的順序號碼組成。方法（method）必須和請求的方法一致。對于對話外的非REGISTER請求來說，
順序號碼可以是任意的。這個順序號碼必須可以由32位的無符號整數(shù)表達，必須小于2^31。只要遵循了上述指導方針，客戶端可以用任意的方法來產(chǎn)生這個Cseq頭域。
講述了在對話中如何創(chuàng)建Cseq例子：Cseq: 4711 INVITE MaxForwardsMaxForwards頭域用來限制請求到他的目的地中間的跳轉(zhuǎn)。它包含一個每隔一個跳轉(zhuǎn)就自動減一的數(shù)字。如果MaxForwards在到達目的之前就減到0，他會報告一個483(太多的路由
)錯誤回應。一個UAC必須為每一個請求填寫一個MaxForwards頭域，這個字段的缺省值應該是70。這個數(shù)字是保證了請求在沒有環(huán)路的SIP網(wǎng)絡中都能夠送達，也保證了在有環(huán)路的時候，盡量
少消耗proxy的資源。如果這個數(shù)字要變小，則必須保證UA知道整個網(wǎng)絡的拓撲結(jié)構(gòu)。 ViaVia頭域是標志了用于事務傳輸?shù)膫鬏斣O備，并且也標志了應答送回的地址。只有當需要通過選擇傳輸設備到達下一個節(jié)點(hop)的時候，才需要在頭域中包含Via域。當UAC創(chuàng)建一
個請求，它必須在頭域中添加一個Via域。protocol 。Via頭域必須包含一個分支(branch)參數(shù)。這個參數(shù)用于區(qū)分請求創(chuàng)建的事務。這個
參數(shù)客戶端和服務器都會使用。除了CANCEL和給非2xx應答的ACK以外，branch參數(shù)對UA發(fā)出的所有的請求來說，在時間和空間上必須唯一。在下邊的講解中，CANCEL請求的branch
參數(shù)必須和他所取消的請求的branch參數(shù)一致。（non－2xx）應答的ACK必須和其對應的的INVITE請求有相同的branch ID。利用branch ID參數(shù)的唯一性來作為事務的ID（transaction ID）,并非RFC 2543的一部分。根據(jù)本標準產(chǎn)生的branch ID必須用”z9h64bK”開頭。這7個字母是一個亂數(shù)cookie（定
義成為7位的是為了保證舊版本的RFC2543實現(xiàn)不會產(chǎn)生這樣的值），這樣服務器收到請求之后，可以很方便的知道這個branch ID是否由本規(guī)范所產(chǎn)生的（就是說，全局唯一的）。
在這樣的要求下，精確的branch ID的格式必須事先有實現(xiàn)的定義。Via頭域中，maddr,ttl,和sentby字段會在transport層處理請求的時候設置（18節(jié)）。 ContactContact頭域提供了訪問后續(xù)請求的特定UA實例的聯(lián)系方法：SIP或者SIPS URI。在任何會建立一個對話的請求中，Contact頭域必須提供和包含一個SIP或者SIPS URI。在這個規(guī)范
中定義的方法中，只有INVITE請求會建立一個會話。對這些請求來說，Contact的作用域是全局性的。這就是說，Contact頭域中包含的URI是UA能夠接收請求的，這個URI必須是有
效的，甚至在對話外的請求中的Contact頭域中的URI也必須是有效的。如果RequestURI或者頭上的Route頭域包含了SIPS URI,Contact頭域也必須是一個SIPS URI。 Supported 和 Require如果UAC支持服務端響應請求的SIP擴展，UAC應該在請求的時候包含一個Supported頭域說明options tags（）描述那些SIP擴展。option tags中出現(xiàn)的擴展說明必須是遵循
RFCs的標準擴展說明。這樣可以防止服務端支持非標準的客戶端擴展實現(xiàn)。在Support頭域中的對于SIP擴展定義中，嚴格遵守不支持試驗性質(zhì)的或者說明性質(zhì)的RFCs擴展，這個也
是由于這些擴展是描述提供商定義的擴展說明。如果UAC要求UAS能夠支持擴展，以便UAS能夠處理UAC的特定請求，那么它必須在請求頭中增加一個Require頭域來說明處理本特定請
求需要什么樣的一個擴展option tags。如果UAC需要請求經(jīng)過的所有proxy都支持它發(fā)出的某個請求的擴展部分，它必須增加一個ProxyRequire頭域來說明需要Proxy支持何種
option tag擴展。如同在Supported頭域指出的，Require和ProxyRequire頭域中的option字段必須限定于RFCs的標準擴展。 附加信息部分在一個新請求創(chuàng)建以后，以上的頭域都被正確初始化了以后，就可以位這個請求增加它所需要的附加頭域了。SIP請求允許包含一個MIMEencoded消息正文。無論請求包含哪種消息
正文，都必須引入頭域來指出這個正文的類型，以及這個正文的一些其他說明。關(guān)于這些頭域的詳細說明。 發(fā)送一個請求于是，我們就開始查找請求發(fā)送的目標。除非有其他的特定說明，目標必須是通過DNS來查找的（參見[4]說明）。如果路由表(route set)中的第一個元素表明這是一個嚴格路由（
strict router,），那么這些過程必須在請求的RequestURI中說明。否則，這些過程在請求中被應用于第一個Route頭域中（如果存在），或者在請求的
RequestURI中（如果Route頭域不存在）。這樣一些過程產(chǎn)生了一系列的地址，端口，和用于傳輸?shù)膫鬏斊?。無論那個URI用在這個[4]中描述的過程的輸入，如果RequestURI指明
了SIPS，那么UA