【導(dǎo)讀】IP電話信令協(xié)議,是采用UTF-8字符集來進(jìn)行編碼的文本協(xié)議。用戶代理表示一個終端系統(tǒng)。它可以是SIP電話機(jī)或者電腦上的SIP軟。UserAgentServer），前者產(chǎn)生請求，后者產(chǎn)生對應(yīng)的響應(yīng)。UAC和UAS是邏輯上的兩個部分，每個終端系統(tǒng)都包含了UAC和UAS的功能。如圖所示，Tesla發(fā)起INVITE（請求），Marconi接收INVITE請求，因此，此時Tesla. 路由決策，并在將請求信息轉(zhuǎn)發(fā)到下一個實(shí)體之前對其進(jìn)行修改。響應(yīng)消息將遍歷請求信。息所經(jīng)的那些服務(wù)器，但順序卻完全相反。當(dāng)一個請求消息到來時，一個能作為代理服務(wù)器的SIP實(shí)。一旦消息轉(zhuǎn)發(fā)完畢，無狀態(tài)代理服務(wù)器將丟棄所有與此消息相關(guān)的信息。列表，以便用戶代理或代理服務(wù)器重新發(fā)送請求消息。ACK消息用于完成會話的建立；3xx：重定向響應(yīng)，表示需采取進(jìn)一步以完成該請求；6xx：全局故障，表示任何服務(wù)器無法完成該請求；應(yīng)消息是UAS發(fā)往UAC。個頭字段和一個消息體組成，其中的消息體是可選。下面分別給出請求消息和響應(yīng)消息的完整的例子。

　　

【正文】 URI 方案：如果一個請求的 RequestURI 使用了代理服務(wù)器不能理解的 URI 方案，代理服務(wù)器應(yīng)當(dāng)用一個 416（不支持的 URI 方案）響應(yīng)拒絕該請求； 168。 最大轉(zhuǎn)發(fā)數(shù)：檢測 MaxForwards 頭字段。當(dāng)有此頭字段，并且其值等于零，那么 SIP 實(shí)體不可以轉(zhuǎn)發(fā)此請求；并且，如果請求方法是 OPTIONS，那么 SIP 實(shí)體可以作為消息的最終接收者進(jìn)行響應(yīng)，否則， SIP 實(shí)體必須返回一個 483（跳數(shù)過多）響應(yīng)； 168。 回路檢測（可選）：當(dāng)代理檢測到一個循環(huán)時，發(fā)送一個 482（檢測到路由循環(huán)）響應(yīng)，具體檢查過程在此不作介紹； 168。 ProxyRequire：此頭字段列出了終端希望代理服務(wù)器支持的擴(kuò)展，如果代理不理解此頭字段的擴(kuò)展能力， SIP 實(shí)體必須返回一個 420（錯誤的擴(kuò)展）響應(yīng)。該響應(yīng)中必須包含一個 Unsupported 頭字段，其中列出那些不能被理解的選項(xiàng)標(biāo)簽； 168。 ProxyAuthorization：如果 SIP 實(shí)體在轉(zhuǎn)發(fā)一個請求之前需要鑒權(quán)證書，則需要先進(jìn)行消息檢查。 如果任何一項(xiàng)檢查失敗，代理服務(wù)器必須象 UAS 那樣處理，并用一個錯誤碼來應(yīng)答。 2． 預(yù)處理路由信息 代理服務(wù)器必須檢查請求消息的 RequestURI。如果請求消息的 RequestURI 是它以前插在RecordRoute 頭字段中的值， 代理服務(wù)器則必須用 Route 頭字段的最后一個值替換RequestURI，并且從 Route 頭字段中刪除該值。在這之后，代理服務(wù)器必須按修改過的請 求來進(jìn)行處理。 上述情況 只有當(dāng)發(fā)送請求到代理服務(wù)器（可能是一個端點(diǎn)）的 SIP 實(shí)體為一嚴(yán)格路由服務(wù)器時才會發(fā)生。為了獲得與這類實(shí)體的后向兼容性，此時對接收消息的修改是必要的。這也使得遵從 RFC3261 的實(shí)體能夠在通過嚴(yán)格路由的代理服務(wù)器時保留 RequestURI。 如果 RequestURI 中包含 maddr 參數(shù)，代理服務(wù)器必須檢查其值是否在自己所負(fù)責(zé)的地址集或主域集中。如果在其中，且對應(yīng)的請求消息是通 過 RequestURI 中指定或缺省的端口和傳輸方式接收的，代理服務(wù)器必須去掉 maddr 參數(shù)和所有非缺省的端口及傳輸方式參數(shù)，并按 照沒有這些參數(shù) 的請求消息來進(jìn)行處理。 代理服務(wù)器收到的某個請求消息中可能有與該服務(wù)器相匹配的 maddr 參數(shù)，但接收該消息時所用的端口和傳輸方式卻與 RequestURI 中指定的不同。這樣的請求需要被轉(zhuǎn)發(fā)到使用RequestURI 中指定的端口和傳輸方式的代理服務(wù)器。 如果請求消息中 Route 頭字段的第一個值指示的就是本代理服務(wù)器，那么它必須將該值從請求消息中刪除。 3． 確定請求發(fā)送的目的地 代理服務(wù)器計(jì)算請求消息的發(fā)送目的地。發(fā)送的目標(biāo)地址集可以由請求消息的內(nèi)容預(yù)先決定，也可以是從某個抽象的定位服務(wù)獲得 。地址集中的每個目的地都被表示成一個 URI。 如果請求的 RequestURI 中包含一個 maddr 參數(shù)， RequestURI 必須被作為唯一的目標(biāo) URI放在目標(biāo)地址集中。 如果 RequestURI 多指示的域不是代理服務(wù)器所負(fù)責(zé)的域， RequestURI 必須被作為唯一的發(fā)送目的地放進(jìn)目標(biāo)地址集中，然后該實(shí)體 必須對該消息進(jìn)行轉(zhuǎn)發(fā)。（許多情況下代理服務(wù)器都可能收到 RequestURI 所指主域不歸自己負(fù)責(zé)的請求消息。比如處理外撥呼叫的防火墻代理服務(wù)器， 就是這種情況可能發(fā)生的一個例子） 如果目標(biāo)地址集不能通 過上述的方法確定，當(dāng)前 SIP 實(shí)體則負(fù)責(zé) RequestURI 中的主域，并且該實(shí)體可以用任何機(jī)制來決定向何處轉(zhuǎn)發(fā)請求。不 論是哪中機(jī)制，其模型都可以化為訪問一個抽象定位服務(wù)的過程?？赡艿臋C(jī)制有：從 SIP 注冊服務(wù)器創(chuàng)建的某個定位服務(wù)獲得信息；讀去數(shù)據(jù)庫；查詢一個 presence 服務(wù)器；使用其它協(xié)議；或者執(zhí)行一個簡單的算法對RequestURI 進(jìn)行替換，等等。當(dāng)訪問一個由注冊服務(wù)器構(gòu)件的定位服務(wù)時，必須 首先對RequestURI 進(jìn)行規(guī)范化，然后才能把它作為查詢索引。這些機(jī)制的輸出結(jié)果被用于構(gòu)造目標(biāo)地址集。 如果 RequestURI 沒有提供足夠的信息使得代理服務(wù)器能夠決定目標(biāo)地址集，代理服務(wù)器應(yīng)當(dāng)返回一個 485（不明確）響應(yīng)。響應(yīng)中應(yīng)當(dāng)包含一個 Contact 頭字段，其中列出了可供嘗試的新地址的 URI。 任何在請求消息中，或者與請求消息相關(guān)的，或者實(shí)體的當(dāng)前環(huán)境相關(guān)的信息都可能用于目標(biāo)地址集的構(gòu)建。例如，根據(jù)某些頭字段和消息體是否出現(xiàn)及其內(nèi) 容如何，或請求消息到達(dá)的時間、或接收請求所用的接口、或以前請求消息的失敗情況，甚至實(shí)體當(dāng)前的可用性級別等等，可能會構(gòu)造出不同的目標(biāo)地址集。 通過上述定位服務(wù)確定了可能的目 標(biāo)地址之后，它們的 URI 就被加入到目標(biāo)地址集中。目標(biāo)地址只能被放置到目標(biāo)地址集一次。根據(jù) URI 相等的定義，一個目標(biāo) URI 已經(jīng)在目標(biāo)地址集中出現(xiàn)，那么它就不能被再次加入該地址集。 如果原請求的 RequestURI 所指定的資源位置不在本代理服務(wù)器負(fù)責(zé)的范圍之內(nèi)，代理服務(wù)器不得在目標(biāo)地址集中加入其他地址。（代理服務(wù)器只有在請求的 RequestURI 是由自己所負(fù)責(zé)的情況下，才能在消息轉(zhuǎn)發(fā)時改變這個 URI） 如果代理服務(wù)器負(fù)責(zé)原始請求的 RequestURI 所指定的資源，則在請求轉(zhuǎn)發(fā)開始之后它可能繼續(xù)向目標(biāo)地址集 加入地址。它可以使用處理過程中獲 得的任何信息來決定新的目標(biāo)地址。比如，代理服務(wù)器可以將一個重定向響應(yīng)（ 3XX 類響應(yīng)）中獲得的 Contact URI 并入目標(biāo)地址集中。如果代理服務(wù)器在構(gòu)造目標(biāo)地址集時使用了動態(tài)信息源（比如查詢一個 SIP 注冊服務(wù)器），它應(yīng)當(dāng)在請求處理過程中監(jiān)視所有信息源的 變化。如果有新的可用地址，那就應(yīng)當(dāng)將其加入目標(biāo)地址集中。同樣的地址決不能被多次加入。 如果在 RequestURI 中指定的某個資源不存在，代理服務(wù)器必須返回一個 404（找不到）響應(yīng)。 按上述所有的方法處理之后，目標(biāo)地址集仍然 為空，代理服務(wù)器就必須返回一個錯誤響應(yīng)，并且應(yīng)當(dāng)是 480（臨時不可用）響應(yīng)。 4． 請求的轉(zhuǎn)發(fā) 只要目標(biāo)地址集非空，代理服務(wù)器就可以開始轉(zhuǎn)發(fā)請求。 對每個目標(biāo)地址，代理服務(wù)器按如下步驟轉(zhuǎn)發(fā)請求（具體操作見 RFC3261）： 168。 復(fù)制收到的原時請求； 168。 更新 RequestURI； 168。 更新 MaxForwards； 168。 添加一個 RecordRoute 頭字段值（可選）； 168。 添加其他頭字段（可選）； 168。 路由信息后處理； 168。 確定下一跳得地址、端口和 傳輸方式； 168。 添加一個 Via 頭字段值； 168。 必要時加入一個 ContentLength 頭字段； 168。 轉(zhuǎn)發(fā)新請求； 168。 設(shè)置定時器 C； 5． 響應(yīng)的處理 當(dāng)一個 SIP 實(shí)體收到響應(yīng)時，首先它會查找與響應(yīng)消息相匹配的客戶端事務(wù)。如果沒有找到，那么該實(shí)體必須作為一個無狀態(tài)代理服務(wù)器來處理這個響應(yīng)。如果事務(wù)相匹配，那么這個響應(yīng)由所匹配的事務(wù)來處理。 客戶端事務(wù)把響應(yīng)消息傳給代理服務(wù)層之后，必須執(zhí)行下述處理（具體操作見 RFC3261）： 168。 查找正確的響應(yīng)上下文； 168。 對臨時響應(yīng)更新定時器 C； 168。 刪除最頂端 Via 頭字段值； 168。 把響應(yīng)消息加到響應(yīng)上下文中； 168。 檢查響應(yīng)是否需要立即轉(zhuǎn)發(fā)； 168。 需要時，從響應(yīng)上下文中選取最優(yōu)的最終響應(yīng)； 168。 必要時匯聚所有的 authorization 頭字段值； 168。 重寫 RecordRoute 頭字段值（可選）； 168。 轉(zhuǎn)發(fā)響應(yīng)消息； 168。 生成任何必要的 CANCEL 請求； 6． CANCEL 的處理 當(dāng)代理服務(wù)器轉(zhuǎn)發(fā)一個最終響應(yīng)，或者當(dāng)它收到 6XX 響應(yīng)時，它都必須對響應(yīng)上下文的所有 未決客戶端事務(wù)發(fā)出一個 CANCEL 請求。另外，代理服務(wù)器在轉(zhuǎn)發(fā)一個臨時響應(yīng)后，也可能收到 UAC 發(fā)送的 CANCEL 請求。 當(dāng)收到 CANCEL 請求時，代理服務(wù)器必須取消與之匹配的響應(yīng)上下文的所有未決客戶端事務(wù)。 當(dāng) CANCEL 請求在由自己的服務(wù)器端事務(wù)處理時，有狀態(tài)代理服務(wù)器不會為它創(chuàng)建新的響應(yīng)上下文。反之，代理服務(wù)器從現(xiàn)有的響應(yīng)上下文中查找與 CANCEL 請求相關(guān)的那個請求所在的服務(wù)器端事務(wù)。如果找到了匹配的響應(yīng)上下文，那么代理服務(wù)器必須立即對 CANCEL請求返回一個 200OK 響應(yīng)。這 種情況下當(dāng)前實(shí)體就作為 一個 UAS。另外，代理服務(wù)器必須為響應(yīng)上下文中的所有未決客戶端事務(wù)產(chǎn)生 CANCEL 請求。 如果沒有找到相匹配的響應(yīng)上下文，當(dāng)前實(shí)體沒有任何與 CANCEL 請求對應(yīng)的請求的信息，它必須以無狀態(tài)方式轉(zhuǎn)發(fā)這個 CANCEL 請求。 總結(jié) 如果沒有相反的本地策略，代理服務(wù)器對于包含 Route 頭字段的請求所執(zhí)行的處理可被總結(jié)為如下幾步： 1。檢查請求的 RequestURI。如果它指示的是一個由當(dāng)前代理服務(wù)器負(fù)責(zé)的資源，那么代理服務(wù)器將用從定位服務(wù)中得到的地址代替它。否則，代理服務(wù)器將不對它做改動。 2。代理服務(wù) 器將檢查最頂端 Route 頭字段中的 URI。如果它指向當(dāng)前代理服務(wù)器，那么將其從 Route 頭字段中刪除。 3。代理服務(wù)器將把請求轉(zhuǎn)發(fā)到最頂端的 Route 頭字段值中 URI 所指的資源位置，如果沒有Route 頭字段出現(xiàn)則轉(zhuǎn)發(fā)到 RequestURI 所指的資源位置。 例子 1． 基本的 SIP 梯形 該示例是一個基本的 SIP“梯形 ”結(jié)構(gòu)， U1P1P2U2,U1 和 U2 表示終端， P1和 P2 表示代理服務(wù)器。兩個代理服務(wù)器都要插入 RecordRoute 頭字段值。這里給出消息流程： U1 發(fā)送 INVITE 給 P1： INVITE sip: SIP/ Contact: sip: P1 發(fā)送 INVITE 給 P2： INVITE sip: SIP/ Contact: sip: RecordRoute: 說明： P1 是一個外撥代理服務(wù)器，它不負(fù)責(zé) ，所以它進(jìn)行 DNS 查詢并將請求發(fā)往那里。它還在請求中加了一個 RecordRoute 頭字段 值 P2 發(fā)送 INVITE 到 U2： INVITE sip: SIP/ Contact: sip: RecordRoute: RecordRoute: 說明： P2 收到了這個請求，它負(fù)責(zé) ，因此它運(yùn)行定位服務(wù)并重寫 RequestURI。它也加入了一個 RecordRoute 頭字段值。因?yàn)檎埱笾袥]有 Route 頭字段，所以它對新的RequestURI 進(jìn)行解析以確定向何處轉(zhuǎn)發(fā)請求。 U2 發(fā)送 200OK到 P2： SIP/ 200 OK Contact:sip: RecordRoute: RecordRoute: 說明：位于 的被叫方收了請求，完全復(fù)制請求中的 RecordRoute 列表；用本機(jī)地址更新 Contact 頭字段。這個 200 響應(yīng)沿著 P2P1U1 的路徑正?；貍?。 此時， U2 將其對話狀態(tài)信息中的遠(yuǎn)端目標(biāo) URI 設(shè)為 sip: 并將其路由集設(shè)為：（ U1 發(fā)送 BYE 到 P1: BYE sip: SIP/ Route: 說明：既然路由集中的所有元素都包含 lr 參數(shù)，則需要添加 Route 頭字段。 P1 發(fā)送 BYE 到 P2: BYE sip: SIP/ Route: 說明： P1 注意到自己不負(fù)責(zé) RequestURI 所指的資源位置，因此它不改變其內(nèi)容。它也確實(shí)發(fā)現(xiàn)自己是 Route 頭字段的第一個值，所以它將該值刪除，并將請求轉(zhuǎn)發(fā)到 P2。 P2 發(fā)送 BYE 到 U2: BYE sip: SIP/ 說明： P2 注意到它不負(fù)責(zé) RequestURI 所指的資源位置（它負(fù)責(zé)的是 ，而不是），因此它也 不改變 RequestURId 的值。 P2 也確實(shí)發(fā)現(xiàn)自己是 Route 頭字段的第一個值，所以將該值刪去，并通過對 RequestURI 進(jìn)行 DNS 查詢 將 BYE 請求轉(zhuǎn)發(fā)到。 2． 穿過一個嚴(yán)格路由的代理服務(wù)器 該示例中，一個對話通過 4 個代理服務(wù)器建立，每個代理服務(wù)器都加入了 RecordRoute 頭字段值。第三個代理服務(wù)器實(shí)現(xiàn)了嚴(yán)格路由過程 。請求消息的流程如下： U1P1P2P3P4U2 到達(dá) U2 的 INVITE 請求包含： INVITE sip: SIP/ Contact: sip: RecordRoute: RecordRoute: RecordRoute: RecordRoute: U2 回應(yīng)以 200OK。之后， U2 基于第一個 Route 頭字段值發(fā)送如下的 BYE 請求給 P4： BYE sip: SIP/ Route: Route: Route: