【正文】 e parametervalue都是大小寫不敏感的。標記詞始終是大小寫不銘感的。除非有特別的指定，引號串的字符串是大小寫敏感的。例如： Contact: sip:alice@。expires=3600和 CONTACT: sip:alice@。 ExPiReS=3600相同。 ContentDisposition: session。handling=optional和 contentdisposition: Session。HANDLING=OPTIONAL相同。下邊的兩個頭域不相同： Warning: 370 devnull “Choose a bigger pipe” Warning: 370 devnull “CHOOSE A BIGGER PIPE” 頭域分類。有一些頭域是僅僅在請求（或者應答）中有效的。這些頭域叫做請求頭域或者應答頭域。如果消息中的頭域與這個消息的類型不匹配（比如在應答消息中出現(xiàn)的請求頭域），這個頭域必須被忽略。20節(jié)定義了每一個頭域的分類。 縮寫格式SIP提供了一個用縮寫格式來表達通用頭域名字的機制。這個有助于避免消息過大而導致通訊層無法傳輸（比如在UDP傳輸?shù)臅r候超過了最大傳輸單元(MTU)）。這個縮寫格式在20節(jié)定義。縮寫格式的消息頭域名字可以在不改變消息語義的情況下替代較大的消息頭域名字。在單個消息中，頭域名字既可以用長的格式，也可以用縮寫格式。在實現(xiàn)中，必須同時支持對長名字和縮寫名字的處理。請求信息，包括這個規(guī)范以后的擴展的新請求，都可以包含一個消息正文體。對消息正文體的解釋依賴域請求的方法（請求類型）。對于應答消息來說，請求方法和應答狀態(tài)（response status code）決定了消息正文體的格式。所有的應答消息都可以有一個消息正文體（body）。 消息正文類型(MessageBodyType)消息中的internet媒體類別必須在ContentType頭域中指明。如果消息正文（body）通過某種形式的編碼（encoding），比如壓縮等等，都必須在ContentEncoding 頭域中指明，否則ContentEncoding域必須忽略。如果可行，消息體的字符集作為Contenttype頭域的值的一部分表達。在RFC2046[11]中定義的多部分”multipart” MIME類型可以在消息體中應用。在由多部分組成的消息體發(fā)送的時候，如果接受方的實現(xiàn)中，包頭域的Accept域中，不包含多部分的標記，那么發(fā)送方必須發(fā)送一個非多部分的session description。[1]SIP消息可以包含二進制的包體或者部分包體。如果發(fā)送方?jīng)]有其他顯示的字符集參數(shù)指出，媒體的文本”text”子類型會是缺省的字符集”UTF8”。 消息體長度在ContentLength頭域中存放了包體的字節(jié)長度。HTTP/“chunked”傳輸編碼方式并不適用于SIP。（備注：chuncked編碼傳輸方式是通過把消息正文體分為一系列的塊來傳輸?shù)?，每一塊有它自己的大小標記） 分幀的SIP消息（Framing SIP Messages）不同于HTTP的是，SIP實現(xiàn)可以使用UDP或者其他非可靠傳輸協(xié)議。每一幀包括一個請求或者應答。第18節(jié)講述了非可靠傳輸?shù)膽?。在處理以面向流的通訊為基礎的SIP消息的時候，必須忽略在開始行之前的CRLF[]。ContentLength頭域用來確定每一個SIP消息在通訊流中的結束位置的。在基于面向流通訊基礎上的SIP消息一定要使用這個頭域。8 一般用戶代理行為一個用戶代理代表了一個終端系統(tǒng)。它包含一個用戶代理客戶端（UAC）,用來產(chǎn)生請求的，它包含一個用戶代理服務端（UAS），用來響應請求的。UAC可以由一些外部的東西來發(fā)出請求和處理應答（比如用戶按了一個按鈕，或者按下了一個電話鍵產(chǎn)生了一個音頻信號等等）。UAS是一個能夠接收請求，并且產(chǎn)生應答的東西，它可以根據(jù)用戶輸入，外部輸入，程序執(zhí)行結果或者其他什么機制來產(chǎn)生應答。當一個UAC發(fā)送一個請求，這些請求可能通過一些PROXY（代理服務器）傳遞到UAS上。當UAS產(chǎn)生一個應答，那么這個應答就會同樣的被傳送到UAC。UAC和UAS的處理由兩個特點。第一，基于請求或者應答是否在一個對話里，第二，基于請求的方法（method）。會話的徹底描述在第12節(jié)；哪里描述了點對點的用戶代理之間的關系，并且通過一些SIP方法建立了會話，比如INVITE方法等。在本節(jié)，我們將討論在處理對話外的請求時，UAC和UAS的方法無關的規(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比如sip:bob@)。如果希望通訊在保密機制下進行，那么就用用戶輸入的字串組成SIPS URI的部分，用戶輸入的將加上”@”和主機的名字作為整個SIPS URI。這個主機的名字通常是請求方的主機名字，這個主機允許處理外發(fā)請求。這個很像”縮位撥號”的機制，這個機制要求請求者自身的主機能夠解釋這個縮位撥號一樣。 URI(如果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頭域。例子：Cseq: 4711 INVITE MaxForwardsMaxForwards頭域用來限制請求到他的目的地中間的跳轉。它包含一個每隔一個跳轉就自動減一的數(shù)字。如果MaxForwards在到達目的之前就減到0，他會報告一個483(太多的路由)錯誤回應。一個UAC必須為每一個請求填寫一個MaxForwards頭域，這個字段的缺省值應該是70。這個數(shù)字是保證了請求在沒有環(huán)路的SIP網(wǎng)絡中都能夠送達，也保證了在有環(huán)路的時候，盡量少消耗proxy的資源。如果這個數(shù)字要變小，則必須保證UA知道整個網(wǎng)絡的拓撲結構。 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擴展定義中，嚴格遵守不支持試驗性質的或者說明性質的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消息正文。無論請求包含哪種消息正文，都必須引入頭域來指出這個正文的類型，以及這個正文的一些其他說明。關于這些頭域的詳細說明。 發(fā)送一個請求于是，我們就開始查找請求發(fā)送的目標。除非有其他的特定說明，目標必須是通過DNS來查找的（參見[4]說明）。如果路由表(route set)中的第一個