【導(dǎo)讀】由于考慮到參與者的實(shí)際情況，這些應(yīng)用的實(shí)現(xiàn)往往是很復(fù)雜的：參與者可能是在。代理間移動(dòng)，他們可能可以有多個(gè)名字，他們中間的通訊可能是基于不同的媒介（比如文本，多媒體，視頻，音頻等）－有時(shí)候是多種媒介一起交互。人們創(chuàng)造了無(wú)數(shù)種通訊協(xié)議應(yīng)用于。實(shí)時(shí)的多媒體會(huì)話數(shù)據(jù)比如聲音，影像，或者文本。為了能夠定位精確的會(huì)話參與者，并且也為了其他的目的，SIP允許創(chuàng)建基礎(chǔ)的work. hosts，并且允許終端用戶注冊(cè)上去，發(fā)出會(huì)話邀請(qǐng)，或者發(fā)出其他請(qǐng)求。SIP也可以邀請(qǐng)參與者參加已經(jīng)存在的會(huì)話，比如多方會(huì)議。SIP顯示的支持名字映射和重定向服務(wù)，這。SIP在建立和維持終止多媒體會(huì)話協(xié)議上，支持5個(gè)方面：。基本的SIP協(xié)議的功能組件并不依賴于這些協(xié)議。要達(dá)到理想的安全程度，SIP提供了一套安全服務(wù)，包。抵制的INVITE通訊請(qǐng)求。在INVITE中有如下的字段：呼叫的唯一標(biāo)志，目的抵制，Alice的地址，Alice和Bob建立會(huì)話的類型。

　　

【正文】 Route: sip: Subject: Lunch Route: sip: Route: sip: Route: sip:, sip: Route: sip: Subject: Lunch Subject: Lunch Route: sip:, sip: sip: 下邊各組是合法的，但是并不相等。 Route: sip: Route: sip: Route: sip: Route: sip: Route: sip: Route: sip: Route: sip:,sip:,sip: 每一個(gè)頭域值的格式是依賴于它的頭域名的。他可以是任意順序的 TEXTUTF8字符，也可以是一個(gè)空格，標(biāo)記，分隔符，引號(hào)括起來(lái)的字串的組合。很多頭域都回附帶一個(gè)通用的域值格式。這個(gè)域值格式是由分號(hào)分開的參數(shù)名和參數(shù)值的組合： fieldname: fieldvalue *(。parametername=parametervalue) 雖然在域值里邊可以有任意數(shù)量的 parametername/parametervalue對(duì)，但是不能允許有相同的 parametername存在（唯一性）。除了特別指出的頭域之外，頭域中的域名、域值、 parameter name parametervalue 都是大小寫不敏感的。標(biāo)記詞始終是大小寫不銘感的。除非有特別的指定，引號(hào)串的字符串是大小寫敏感的。例如： Contact: sip:。expires=3600 和 CONTACT: sip:。 ExPiReS=3600 相同。 ContentDisposition: session。handling=optional 和 contentdisposition: Session。HANDLING=OPTIONAL 相同。 下邊的兩個(gè)頭域不相同： Warning: 370 devnull “Choose a bigger pipe” Warning: 370 devnull “CHOOSE A BIGGER PIPE” 小虎 20200525 00:03 頭域分類。 有一些頭域是僅僅在請(qǐng)求（或者應(yīng)答）中有效的。這些頭域叫做請(qǐng)求頭域或者應(yīng)答頭域。如果消息中的頭域與這個(gè)消息的類型不匹配（比如在應(yīng)答消息中出現(xiàn)的請(qǐng)求頭域），這個(gè)頭域必須被忽略。 20節(jié)定義了每一個(gè)頭域的分類。 縮寫格式 SIP提供了一個(gè)用縮寫格式來(lái)表達(dá)通用頭域名字的機(jī)制。這個(gè)有助于避免消息過大而導(dǎo)致通訊層無(wú)法傳輸（比如在 UDP 傳輸?shù)臅r(shí)候超過了最 大傳輸單元 (MTU)）。這個(gè)縮寫格式在 20節(jié)定義。 縮寫格式的消息頭域名字可以在不改變消息語(yǔ)義的情況下替代較大的消息頭域名字。在單個(gè)消息中，頭域名字既可以用長(zhǎng)的格式，也可以用縮寫格式。在實(shí)現(xiàn)中，必須同時(shí)支持對(duì)長(zhǎng)名字和縮寫名字的處理。 請(qǐng)求信息，包括這個(gè)規(guī)范以后的擴(kuò)展的新請(qǐng)求，都可以包含一個(gè)消息正文體。對(duì)消息正文體的解釋依賴域請(qǐng)求的方法（請(qǐng)求類型）。對(duì)于應(yīng)答消息來(lái)說(shuō)，請(qǐng)求方法和應(yīng)答狀態(tài)（ response status code）決定了消息正文體的格式。所有的應(yīng)答消息都可以有一個(gè)消息正文體（ body）。 消息正文類型 (MessageBodyType) 消息中的 inter媒體類別必須在 ContentType頭域中指明。如果消息正文（ body）通過某種形式的編碼（ encoding），比如壓縮等等，都必須在 ContentEncoding 頭域中指明，否則ContentEncoding 域必須忽略。如果可行，消息體的字符集作為 Contenttype 頭域的值的一部分表達(dá)。 在 RFC2046[11]中定義的多部分” multipart” MIME類型可以在消息體中應(yīng)用。在由多部分組成的消息 體發(fā)送的時(shí)候，如果接受方的實(shí)現(xiàn)中，包頭域的 Accept 域中，不包含多部分的標(biāo)記，那么發(fā)送方必須發(fā)送一個(gè)非多部分的 session description。 SIP 消息可以包含二進(jìn)制的包體或者部分包體。如果發(fā)送方?jīng)]有其他顯示的字符集參數(shù)指出，媒體的文本” text”子類型會(huì)是缺省的字符集” UTF8”。 消息體長(zhǎng)度 在 ContentLength頭域中存放了包體的字節(jié)長(zhǎng)度。第 。 HTTP/“ chunked”傳輸編碼方式并不適用于 SIP。（備注： chuncked編碼傳輸方式是通過把消息正文體分為一系列的塊來(lái)傳輸?shù)?，每一塊有它自己的大小標(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)求可能通過一些 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)系，并且通過一些 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ī)制。通過用 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)求的示例（通過 INVITE請(qǐng)求建立連接，第 13節(jié)），（通過 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)過的。通常，他們是由用戶或者服務(wù)提供商手工在 UA上設(shè)置的，或者通過一些非 SIP 的方法自動(dòng)設(shè)置。當(dāng)一個(gè)提供商希望配置一個(gè)出口 proxy 給一個(gè) UA，我們強(qiáng)烈建議通過一個(gè)預(yù)置一個(gè)單個(gè) URI路由表的方式來(lái)實(shí)現(xiàn)，這個(gè)單個(gè)路由就是出口 proxy。 當(dāng)要使用預(yù)置路由表 (route set)，必須提供 RequestURI和 Route頭域（在 細(xì)描述）（甚至在沒有對(duì)話存在的時(shí)候也必 須提供），并且把 RequestURI當(dāng)作遠(yuǎn)端目標(biāo) URI。 TO To 頭域是第一個(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 可以通過無(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:)。如果希望通訊在保密機(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)過的主機(jī)都會(huì)有機(jī)會(huì)來(lái)處理這個(gè)請(qǐng)求。比如，一個(gè)用戶在機(jī)場(chǎng)可能登陸機(jī)場(chǎng)的代理服務(wù)器，并且通過機(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ì)話還沒有建立，那么 tag就不能存在。 。 下邊這個(gè)例子是一個(gè) To 頭域的例子： To: Carol sip: From From 頭域包含了請(qǐng)求發(fā)起者的邏輯標(biāo)志，可能是用戶的 addressofrecord。就像 To 頭域一樣， From 頭域也包含一個(gè) URI 并且可以包含一 個(gè)顯示的姓名。 SIP 可以用這個(gè)頭域來(lái)實(shí)現(xiàn)對(duì)請(qǐng)求的檢查和選擇一個(gè)規(guī)則進(jìn)行對(duì)請(qǐng)求的處理（比如，自動(dòng)的呼叫拒絕，凡是 x人發(fā)過來(lái)的東西，一律無(wú)視）。同樣的，因?yàn)?From頭域包含的是邏輯名字，所以 From URI也可以不包含 IP 地址或者 UA對(duì)應(yīng)的主機(jī)名字 FQDN。 From頭域可以包含一個(gè)顯示姓名。在客戶身份隱藏的情況下，一個(gè) UAC應(yīng)該使用顯示名字”Anonymous”，連通一個(gè)語(yǔ)法正確，但是沒有意義的 URI(比如： sip:)。通常，用戶或者用戶的本地主機(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ù)。 tag的詳細(xì)描述。 節(jié)有更深入的資料。 例子： From: “Bob” sips: 。 tag=a48s From: sip:。tag=887s From: Anonymous sip:。tag=hyh8 CallID CallID 是一個(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是大小寫敏感的，并且通過簡(jiǎn)單字節(jié) /字 節(jié)的來(lái)進(jìn)行比較。 采用密碼亂序隨機(jī)串可以降低會(huì)話被竊聽的機(jī)會(huì)，并且降低 CallID重復(fù)的沖突。不規(guī)定或者要求使用用戶界面來(lái)選擇輸入 CallID頭域的值。參見 。 例子： CallID: Cseq Cseq