【正文】 thorization 授權(quán) Authorization: Digestusername=Cust1,realm=, nonce=9c8e88df84f1cec4341ae6e5a359, opaque=,uri=sip:, response=e56131d19580cd833064787ecc Callinfo 呼叫信息 CallInfo: m/。 一個完整的 SIP 請求消息如下所示： INVITE sip: SIP/ Via: SIP/:5060。位置服務器存儲并且向用戶返回可能的位置信息。 圖 一個簡單的 SIP 呼叫的例子 如圖 所示， Tesla 發(fā)起 INVITE（請求）， Marconi 接收 INVITE 請求，因此，此時 Tesla就是用戶代理客戶端 （ UAC）， Marconi 是用戶代理服務器端（ UAS）；會話建立后， Marconi發(fā)起 BYE（結(jié)束）請求， Tesla 發(fā)送對應的響應，因此，此時 Marconi 就是用戶代理客戶端（ UAC）， Tesla 是用戶代理服務器端（ UAS）。 UAC 和 UAS 是邏輯上的兩個部分，每個終端系統(tǒng)都包含了 UAC 和 UAS 的功能。 定位服務器 定位服務器（ Location Server）不是 SIP 實體，但是它們是任何實用 SIP 協(xié)議的體系結(jié)構(gòu)中非常重要的一部分。 下面分別給出請求消息和響應消息的完整的例子。 tag=2443a8f7 Via 通過 Via: SIP/。 To 頭字段等價性的判定同 From 頭字段。該頭字段用于把某對話中 的事務進行排序且提供了一種唯一標 識某事務的方法（即INVITE、 ACK等 method），并能夠區(qū)分某請求是新的請求還是從發(fā)的請求。 SDP 介紹 會話描述協(xié)議（ SDP， Session Description Protocol）規(guī)定了對描述會話的必要信息怎樣進行編碼。 如果 SDP 語法分析器不能識別某一類型 (Type),則整個描述丟失 。 各頭字段的說明見上文。branch=z9hG4bKfw19b 。branch= z9hG4Bk412kg 。branch=z9hG4bK392kf 。 CANCEL 請求不能包含任何 Require 或 ProxyRequire 頭字段。如果最終響應沒有發(fā)送，那么 UAS 的處理 方式將取決于原請求的類型。 代理服務器是一個邏輯 SIP 實體。 代理服務器的兩種類型 RFC3261 中規(guī)定，代理服務器分為有狀態(tài)代理服務器和無狀態(tài)代理服務器兩種類型。當無狀態(tài)代理收到一個應答時，它僅僅基于通過 Via 頭字段的分析來決定路徑，并且它不為之維持狀態(tài)。 合理的語法：任何與請求的有效性相關的消息內(nèi)容，或者與請求的轉(zhuǎn)發(fā)相關的消息內(nèi)容，其構(gòu)造必須正確。為了獲得與這類實體的后向兼容性，此時對接收消息的修改是必要的。當訪問一個由注冊服務器構(gòu)件的定位服務時，必須 首先對RequestURI 進行規(guī)范化，然后才能把它作為查詢索引。 如果在 RequestURI 中指定的某個資源不存在，代理服務器必須返回一個 404（找不到）響應。如果事務相匹配，那么這個響應由所匹配的事務來處理。如果找到了匹配的響應上下文，那么代理服務器必須立即對 CANCEL請求返回一個 200OK 響應。它還在請求中加了一個 RecordRoute 頭字段 值 P2 發(fā)送 INVITE 到 U2： INVITE sip: SIP/ Contact: sip: RecordRoute: RecordRoute: 說明： P2 收到了這個請求，它負責 ，因此它運行定位服務并重寫 RequestURI。請求消息的流程如下： U1P1P2P3P4U2 到達 U2 的 INVITE 請求包含： INVITE sip: SIP/ Contact: sip: RecordRoute: RecordRoute: RecordRoute: RecordRoute: U2 回應以 200OK。代理服務器將把請求轉(zhuǎn)發(fā)到最頂端的 Route 頭字段值中 URI 所指的資源位置，如果沒有Route 頭字段出現(xiàn)則轉(zhuǎn)發(fā)到 RequestURI 所指的資源位置。另外，代理服務器在轉(zhuǎn)發(fā)一個臨時響應后，也可能收到 UAC 發(fā)送的 CANCEL 請求。 必要時加入一個 ContentLength 頭字段； 168。比如，代理服務器可以將一個重定向響應（ 3XX 類響應）中獲得的 Contact URI 并入目標地址集中。（許多情況下代理服務器都可能收到 RequestURI 所指主域不歸自己負責的請求消息。 2． 預處理路由信息 代理服務器必須檢查請求消息的 RequestURI。 將請求向每個目的地轉(zhuǎn)發(fā)； 168。很多無狀態(tài)的處理步驟和有狀態(tài)的時候很類似。當請求消息在不用類型的傳輸方式之間轉(zhuǎn)發(fā)時，代理服務器必須采用有狀態(tài)模式，代理服務器的事務用戶必須保證消息的可靠傳輸。branch=z9hG4Bk5619b To: G. Marconi From: Nikola Tesla CallID: CSeq: 5 INVITE 6． ACK MESSAGE ACK sip: SIP/ Via: SIP/:5060。 CANCEL 請求不包含 Require 頭字段?？蛻舳水a(chǎn)生的 CANCEL 必須只能有一個 Via 頭字段值，并與被取消請求的頂端 Via 值相匹 配。然后對 BYE 返回 2XX 響應。這個響應應當包含一個 Warning 頭域（用來提供給請求方，提供這個拒絕的原因）。 一個例子（圖 ） MESSAGE INVITE sip: SIP/ Via: SIP/:5060。三次握手過程的完成，唯一標識了會話的成功建立。接下來的行直到媒體流部分或者會話描述的終點，提供了整個會話的信息。舉例如下： RecordRoute: Route 頭字段有一個代理服務器列表，用來指定請求消息的路由。那么， A發(fā)送 BYE 請求時，就是通過不同的 CallID 來選擇結(jié)束那個會話。一般默認為 70。 Header Fields 頭字段提供了關于請求（或應答）的消息和關于這些消息所包含的消息體的信息。下面用 “1xx”標識狀態(tài)碼為 “100199”之間的響應。這些信息將影響它對后續(xù)的、與先前接收的某一請求相關的信息的處理。 SIP 實體 SIP 協(xié)議定義了多個實體，理解它們在使用 SIP 協(xié)議的體系結(jié)構(gòu)中所起的不同作用是至關重要的。 代理服務器是一個邏輯 SIP 實體。一些定位服務器實用輕量目錄訪問協(xié)議（ LDAP， Lightweight Directory Access Protocol） [RFC1777]和 SIP 服務器進行通信。請求行的格式如下所示，由方法名、請求 URI和協(xié)議版本組成，各部分之間均用一個空格字符進行分隔。本字段還可以包含下列參 數(shù)： maddr、 ttl、 received和 brance。 而 RequestURI 含有在信令路徑中下一跳的地址，并因此在路途中被每 個代理改變。 Contact 頭字段的值中還可以包含一個顯示名稱、含有 URI 參數(shù)的 URI 和頭字段參數(shù)。一個 SDP 描述含有會話級信息和媒體級信息。 在會話建立成功以后，任何一端 UA 可以通過發(fā)送 reINVITE 請求來調(diào)整會話，修改會話的某些屬性，例如：增加或刪除媒體流，改變媒體發(fā)送或接受地址等。 SDP 請求和響應這個協(xié)商過程，不能并行，只能當一次交互完成之后才能發(fā)起新的協(xié)商過程。 reINVITE 請求的產(chǎn)生 reINVITE 過程所采用的 SDP 協(xié)商過程與建立會話的 INVITE 過程相同：會話中的任意一方可以通過在 reINVITE 消息中攜帶一個新的 SDP 請求來更新會話內(nèi)容；或者， reINVITE 可以不攜帶 SDP，讓其對方在 200OK 中攜帶 SDP。 UAC 行為 會話中的任意一方可以通過發(fā)送 BYE 請求來結(jié)束已經(jīng)建立的會話。 CANCEL 請求最適合于 INVITE 請求，因為它會需要很長的時間來產(chǎn)生響應。CANCEL 請求的目的地址、端口和傳輸方式必須與原請求的相同。 CANCEL 的響應消息被傳遞給一個服務器 端事務以便發(fā) 送。 一旦消息轉(zhuǎn)發(fā)完畢，無狀態(tài) 代理服務器將丟棄所有與此消息相關的消息。處理之后的請求送給代理服務器核心層，核心層決定將請求路由到何 處，選擇一個或多個下一跳位置。進一步說，當無狀態(tài)的處理一個請求的時候，這個節(jié)點并不產(chǎn)生它自己的 100（ Trying）或者其他臨時應答。 最大轉(zhuǎn)發(fā)數(shù)：檢測 MaxForwards 頭字段。這樣的請求需要被轉(zhuǎn)發(fā)到使用RequestURI 中指定的端口和傳輸方式的代理服務器。例如，根據(jù)某些頭字段和消息體是否出現(xiàn)及其內(nèi) 容如何，或請求消息到達的時間、或接收請求所用的接口、或以前請求消息的失敗情況，甚至實體當前的可用性級別等等，可能會構(gòu)造出不同的目標地址集。 更新 RequestURI； 168。 把響應消息加到響應上下文中； 168。檢查請求的 RequestURI。 此時， U2 將其對話狀態(tài)信息中的遠端目標 URI 設為 sip: 并將其路由集設為：（ U1 發(fā)送 BYE 到 P1: BYE sip: SIP/ Route: 說明：既然路由集中的所有元素都包含 lr 參數(shù)，則需要添加 Route 頭字段。它也確實發(fā)現(xiàn)自己是 Route 頭字段的第一個值，所以它將該值刪除，并將請求轉(zhuǎn)發(fā)到 P2。否則，代理服務器將不對它做改動。 需要時，從響應上下文中選取最優(yōu)的最終響應； 168。 添加一個 RecordRoute 頭字段值（可選）； 168。目標地址只能被放置到目標地址集一次。 3． 確定請求發(fā)送的目的地 代理服務器計算請求消息的發(fā)送目的地。 回路檢測（可選）：當代理檢測到一個循環(huán)時，發(fā)送一個 482（檢測到路由循環(huán)）響應，具體檢查過程在此不作介紹； 168。下面介紹的具體行為就是針對有狀態(tài)代理服 務器。核心層從客戶端事務收集響應，并依據(jù)這些響應來向服務器端事務發(fā)送響應。這些信息將影響它對后續(xù)的、與先前接收的某一請求相關的消息的處理。branch=z9hG4Bk5619b MaxForwards: 70 To: G. Marconi From: Nikola Tesla CallID: CSeq: 5 INVITE Subject: About That Power Outage... Contact: ContentType: application/sdp ContentLength: 158 v=0 o=Tesla 2890844526 2890844526 IN IP4 s=Phone Call c=IN IP4 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 2． 180 Ringing MESSAGE SIP/ 180 Ringing Via: SIP/:5060。事務用戶假定原請求的方法是除了 CANCEL 或 ACK之外的任何一個，并進行事務匹配，匹配到事務將被取消。 代理服務器和 UAC 都可以產(chǎn)生并發(fā)送 CANCEL 請求。 BYE 請求對應一個新的事務。 reINVITE 不會被分 岔（分岔成為多份 INVITE，發(fā)送到不同地址），因此只可能收到一個最終應答（不會分岔的原因是，會話已經(jīng)建立，那么 reINVITE 消息中的 RequestURI 將是目標 UA 的地址，會準確無誤地送到）。當 UAS 收到消息后，可以按以下幾種進行：正在處理，發(fā)送 1XX；重定向， UAS 希望將此請求重新發(fā)送到另一地址，發(fā)送 3XX；拒絕，發(fā)生了某種錯誤，發(fā)送 4XX 或 5XX 或 6XX；接受，發(fā)送 2XX。對端同意結(jié)束，則發(fā)送 200 OK應答，結(jié)束會話成功。例如，它能成 為會話始發(fā)者或者會話的名字。這些參數(shù)只用于 REGISTER 請求及其響應以及 3xx 響應。這可能與對話的發(fā)起者并不同。 Via 頭字段的縮寫形式為 v，例如： Via: SIP/:5060。請求行的格式如下： 格式： RequestLine = Method RequestURI SIPVersion Method：方法表示請求的類型，核心的類型有 6 種， INVITE， ACK， BYE， CANCEL，REGISTER 和 OPTIONS RequestURI：請求的 URI 表示此請求將要被發(fā)送的目標地址 SIPVersion：一般為 SIP/ 例子 ： INVITE sip: SIP/ 請求頭字段 見 節(jié)。 INVITE 消息用于發(fā)起一個新的會話； ACK消息用于完成會話的建立； BYE 消息用于結(jié)束一個會話； C