在一個(gè)新的請求創(chuàng )建以后，前面提到的那些頭域已經(jīng)被構建。添加任何額外的可選頭域，需要指定具體的method。

　　SIP請求可以包含一個(gè) MIME解碼的消息體。無(wú)論在請求中包含什么樣的消息體，某些頭域必須進(jìn)行規范化處理，進(jìn)行內容中的字符整合。更多關(guān)于這些頭域的說(shuō)明，參考章節 20.11 到 20.15。

　　請求的目的地是通過(guò)計算獲得的。除非，在發(fā)送請求的路徑存在一個(gè)邏輯策略強制操作，否則請求目的地必須是通過(guò)DNS處理流程來(lái)處理，具體處理描述參考 [4]。如果在route set的第一個(gè)要素表示是嚴格路由的話(huà)（導致重構請求，具體描述在Section 12.2.1.1）， 這個(gè)處理流程也必須使用在請求的Request-URI中。否則，這個(gè)流程使用在請求中的第一個(gè)Route頭中（如果存在的話(huà)）或如果當前沒(méi)有Route的時(shí)候，使用在請求的Request-URI。這些流程產(chǎn)生了按序的設置組，包括了地址，端口和參數方式。在處理流程中，URL作為輸入數據，他們的處理流程不依賴(lài)于URL本身，如果Request-URI設置了一個(gè)SIPS的源，UAC必須遵從處理流程 [4]，輸入的URL是一個(gè)SIPS URI。

　　本地策略可以設定一系列可選的目的地地址。如果Request-URI包含一個(gè)SIPS URI，任何可選目的地地址必須支持TLS連接。除此之外，如果請求中沒(méi)有包含Route頭的話(huà)，對可選目的地沒(méi)有任何限定設置。對于已存在的route set來(lái)說(shuō)，通過(guò)這樣的方式，它可以提供一個(gè)簡(jiǎn)單可選 方式來(lái)設定一個(gè)outbound proxy 代理。但是，不推薦使用那種方式來(lái)設置一個(gè)outbound proxy；應該通過(guò)一個(gè)單URL使用一個(gè)已存在的route set替代設置方式。 如果一個(gè)請求中包含一個(gè)Route頭的話(huà)，這個(gè)請求應該被發(fā)送到最頂部的Route地址，但是這個(gè)請求也可以被發(fā)送到任何服務(wù)器，只要UA認可其身份，其身份設置是通過(guò)Route和Request-URI 策略設定的。具體的策略設定在此規范中（相反的規范設置RFC 2543）。尤其是一個(gè)UAC配置了outbound proxy，它應該嘗試發(fā)送請求到一個(gè)地址，這個(gè)地址應該是第一個(gè)Route頭域地址 ，而不是調整發(fā)送策略，這個(gè)策略發(fā)送所有消息到這個(gè)outbound proxy。

　　這樣做的目的可以確保outbound proxies不添加Record-Route頭域值，這些頭值將會(huì )被丟出后續的請求路徑。它允許不能解析第一個(gè)Route URI的終端對outbound proxy代表執行任務(wù)。

　　UAC應該遵從對stateful要素定義的處理流程，這個(gè)流程在[4]有具體的定義，UAC應該一直嘗試每個(gè)地址直到連接到一個(gè)服務(wù)器地址。 每個(gè)嘗試連接都構成一個(gè)新的事務(wù)，并且因此每個(gè)攜帶最頂部Via頭值的傳輸都會(huì )有一個(gè)新的branch參數值。進(jìn)一步說(shuō)，在Via頭中的傳輸值被設置為傳輸方式設定的值。無(wú)論這個(gè)值怎么設置，這個(gè)值是傳輸方式針對目的地服務(wù)器決定的。

　　響應消息首先是通過(guò)傳輸層進(jìn)行處理，然后在傳輸到事務(wù)層。事務(wù)層執行自己的處理流程，然后再傳遞回TU處理。在TU中的大部分響應處理流程是和具體的method相關(guān)的。但是，一些基本的處理方式不依賴(lài)于methods本身。

　　在一些情況下，一些由事務(wù)層返回的響應消息不是SIP消息，是一個(gè)事務(wù)層錯誤。當從事務(wù)層收到一個(gè)超時(shí)錯誤時(shí)，它必須被作為一個(gè)408錯誤。如果由傳輸層報告了一個(gè)致命的傳輸錯誤（通常情況下，是因為一個(gè)UDP中的致命ICMP錯誤或TCP的連接錯誤），這種狀態(tài)必須被視為一個(gè)503錯誤代碼（服務(wù)不可用）。

　　UAC必須處理任何無(wú)類(lèi)別等級的最終響應消息，并且UAC也必須可以處理任何x00類(lèi)別的響應消息。例如，如果一個(gè)UAC收到一個(gè)無(wú)類(lèi)別響應代碼是431的響應消息，此UAC可安全地認為可能在請求中有什么錯誤發(fā)生。一個(gè)UAC必須視臨時(shí)響應消息是不同于100響應的，它也不會(huì )被視為183響應消息。UAC必須能夠處理100響應和183響應消息。

　　如果在響應消息中出現了一個(gè)以上的Via頭域值，此UAC應該丟棄這個(gè)消息。

　　多個(gè)出現的Via頭域值是請求發(fā)起方置入的值，這些消息是錯誤設置或者配置文件損害導致。

　　對于轉發(fā)協(xié)議的處理上（例如，301響應狀態(tài)碼），客戶(hù)端應該基于轉發(fā)請求，在Contact頭中使用URL（s）重新構建一個(gè)或多個(gè)新的請求。這個(gè)過(guò)程類(lèi)似于代理對3xx類(lèi)別響應的遞歸處理，具體的細節參考16.5和16.6章節。客戶(hù)端啟動(dòng)時(shí)攜帶初始的目標地址列表，其中包含完整的URL。這是初始請求的Request-URI。 如果客戶(hù)端希望基于3xx重構新的請求，它會(huì )置入這些URLs在目標列表中。在此規范中，對象的限制是，一個(gè)客戶(hù)端可以選擇哪個(gè)URLs可以置入到目標組設置。當代理遞歸發(fā)生時(shí)，客戶(hù)端處理3xx類(lèi)別響應時(shí)，它一定不能再次添加任何已給定的URL到目標組中。如果初始的請求已經(jīng)在Request-URL中有一個(gè)SIPS URL，客戶(hù)端可以選擇遞歸到一個(gè)非-SIPS URI，但是應該通知轉發(fā)用戶(hù)，這是一個(gè)不安全的URL。

　　任何新請求可以接收3xx響應，這些響應自己包含初始的URL，這些URL作為contact。可以配置兩個(gè)地址互相轉發(fā)。在目標地址組置入一個(gè)給定的URL，其目的是防止無(wú)限轉發(fā)環(huán)路發(fā)生。

　　當目的地組設置增加時(shí)，客戶(hù)端可以以任何順序對URLs生成新的請求。一般的機制是在Contact頭中設置一個(gè)"q"參數值來(lái)表示順序。對URL生成的請求可以是并行方式或連續生成方式。一種方式是通過(guò)連續方式處理遞減的q-值組，并且以并行方式處理在每個(gè)q-值組的URL。另外一種方式是按照遞減的q-值順序，僅執行連續處理，在相同q-值的contacts之間任意選擇一個(gè)值。

　　如果連接在列表中的contact失敗，繼續連接列表中的下一個(gè)地址，直到列表地址連接全部失敗。如果地址連接全部失敗的話(huà)，那么這個(gè)請求就已經(jīng)失敗。

　　失敗結果應該通過(guò)失敗響應碼來(lái)檢測（響應碼高于399）；對網(wǎng)絡(luò )錯誤來(lái)說(shuō)，客戶(hù)端事務(wù)層將會(huì )對事務(wù)層用戶(hù)報告傳輸層所發(fā)生的錯誤。注意，一些響應碼（詳情參見(jiàn)8.1.3.5）表示請求可被重新獲取；重新發(fā)送到請求不應該被認為是失敗響應。

　　當收到針對某個(gè)特定contact地址的失敗時(shí)，客戶(hù)端應該嘗試下一個(gè)contact地址。這樣就會(huì )導致針對發(fā)送的新請求創(chuàng )建一個(gè)新客戶(hù)事務(wù)。

　　為了在3xx響應中基于一個(gè)contact地址創(chuàng )建一個(gè)請求，除了“method-param”和 “header”URI（參考 Section 19.1.1 章節對參數的定義）以外，UAC必須從目標組中拷貝所有URL到Request-URI。它使用“header”參數為新請求創(chuàng )建header頭值，覆蓋和轉發(fā)請求中相關(guān)的頭域值，具體操作規范參考Section 19.1.5。

　　注意，在一些例子中，在contact地址中，已經(jīng)構成通信關(guān)系的頭可以替換追加到已存在的請求的頭中，這些請求的頭是在初始轉發(fā)請求中的頭。作為一個(gè)一般規則，如果頭域可以接受以逗號隔離的域值列表，那么新的頭值可以追加到初始轉發(fā)到請求中。如果頭域不能接受支持追加多個(gè)值的話(huà)，初始轉發(fā)請求中的值可以被在contact地址中已經(jīng)構成通信關(guān)系的頭域值覆蓋。例如，如果返回的contact地址攜帶了如下值的話(huà)：

　　那么，在初始轉發(fā)請求中的Subject頭可以被覆蓋，但是這個(gè)HTTP URL很少被追加到任何已存在的Call-Info頭值中。

　　規范推薦UAC重用在初始轉發(fā)請求中同樣的To，From和Call-ID，但是UAC例如也可以選擇更新Call-ID支持新的請求。

　　最后，一旦一個(gè)新的請求生成以后，新請求使用一個(gè)新客戶(hù)端事務(wù)發(fā)送這個(gè)請求，因此，它必須在最頂部的Via頭中生成一個(gè)新的branch ID。關(guān)于這一討論，參考Section 8.1.1.7。

　　從其他角度所期望的，轉發(fā)響應接收方發(fā)送到請求應該重用初始請求的頭域和消息體。

　　在一些例子中，Contact頭域值可能在UAC端被臨時(shí)或永久緩沖保存，這取決于收到的狀態(tài)碼和內部超時(shí)設置狀態(tài)。查看21.3.2 和21.3.3章節介紹。

　　未完繼續……