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