13.2.2 Processing INVITE Responses
一旦INVITE傳遞到INVITE的客戶(hù)端事務(wù)，UAC將會(huì )等待此INVITE的響應。如果此INVITE的客戶(hù)端事務(wù)返回一個(gè)超時(shí)而不是一個(gè)響應，此響應是TU如果已收到了一個(gè)408（Request Timeout）響應的話(huà)，它充當一個(gè)響應，此響應就像在Section 8.1.3討論的一樣。
13.2.2.1 1xx Responses
在收到一個(gè)或者多個(gè)最終響應之前，可能抵達零，一個(gè)或者多個(gè)臨時(shí)響應。對一個(gè)INVITE請求來(lái)說(shuō)，臨時(shí)響應能夠創(chuàng )建“early dialogs”。如果在臨時(shí)響應的TO中有一個(gè)tag標簽的話(huà)，并且如果此響應的dialog ID 不能匹配已存在的dialog，將創(chuàng )建一個(gè)新的dialog，創(chuàng )建流程在Section 12.1.2中定義。
僅需要early dialog的狀態(tài)是，初始INVITE事務(wù)完成之前，如果UAC需要在其dialog中對其peer發(fā)送一個(gè)請求，UAC才需要early dialog。只要此dialog在早期狀態(tài)的話(huà)，臨時(shí)響應中出現header頭域是可以接受的，例如，在臨時(shí)響應中的Allow 頭包含methods，當處理狀態(tài)在早期狀態(tài)時(shí)，這些methods可以用在此dialog中。
13.2.2.2 3xx Responses
一個(gè)3xx響應可以包含一個(gè)或者多個(gè)Contact頭，這些contact頭提供新的地址，這些地址是被呼叫方可達地址。根據3xx狀態(tài)碼的不同（Section 21.3），UAC可能選擇去嘗試這些不同的新地址。
13.2.2.3 4xx, 5xx and 6xx Responses
針對INVITE消息，可能收到一個(gè)單個(gè)非-2xx最終響應。4xx，5xx和6xx響應中可能包含一個(gè)Contact頭域值，此值表示一個(gè)位置，此處發(fā)現關(guān)于錯誤的其他信息。后續最終響應（在錯誤條件下僅抵達的）必須被忽略。
在收到非-2xx最終響應的回復以后，所有早期dialogs將會(huì )結束。
已經(jīng)收到非-2xx最終響應后，UAC core認為INVITE事務(wù)已完成。此INVITE客戶(hù)端事務(wù)處理會(huì )針對此響應來(lái)處理ACKs生成（see Section 17）。
13.2.2.4 2xx Responses
因為分叉代理的原因，一個(gè)單INVITE請求的多個(gè)2xx響應會(huì )抵達UAC端。每個(gè)響應通過(guò)To頭中的標簽參數加以區別，每個(gè)響應代表一個(gè)不同的dialog，這些dialog具有不同的dialog identifier身份確認消息。
如果在2xx響應中斷dialog identifier匹配了當前存在的dialog的dialog identifier，此dialog必須被遷移到"confirmed" 確認狀態(tài)，并且，在此dialog的路由組必須被重新計算，其算法基于2xx響應，按照的Section 12.2.1.2流程來(lái)處理。否則，在"confirmed" 狀態(tài)中的一個(gè)新dialog必須重構，構建流程按照Section 12.1.2處理。
注意，只有一小部分的狀態(tài)需要重新計算，這部分狀態(tài)是route set。在此dialog中其他狀態(tài)部分例如最高序列號的部分（遠端或者本地的）無(wú)需重新計算。route set 部分的計算僅為了支持向后兼容。RFC 2543 沒(méi)有在1xx響應中強制執行Record-Route頭的檢查，只有在2xx支持。，因為，可能在早期的dialog中，mid-dialog請求已經(jīng)被發(fā)送出去，并且可能執行了其他的修改，例如修改了序列號，因此，我們不能更新整個(gè)dialog的狀態(tài)。
UAC core 必須對每個(gè)從事務(wù)層收到的2xx生成一個(gè)ACK請求。除了認證需要的CSeq和頭域，Ack請求的頭域構建方式和任何在dialog中的一樣（Section 12)。CSeq 頭的序列號必須和INVITE確認的一樣，但是CSeq method 必須是ACK。就像INVITE一樣，ACK必須包含同樣的安全信息。如果2xx包含一個(gè)offer消息（基于上面的規則），此ACK必須在其消息體中傳遞一個(gè)answer消息。如果在2xx響應中的offer沒(méi)有被接受，UAC core必須在A(yíng)CK中生成一個(gè)有效的answer消息，并且馬上發(fā)送一個(gè)BYE。
一旦ACK構建好以后，使用[4]中的處理流程來(lái)決定目的地地址，端口和傳輸方式。但是，為了傳輸流程，請求將會(huì )直接傳遞到傳輸層，而不是傳輸到客戶(hù)事務(wù)層。這是因為UAC core處理ACK的重傳，不是事務(wù)層處理。每次ACK抵達觸發(fā)2xx最終響應的重新傳輸ACK必須被傳遞到客戶(hù)傳輸層。
第一個(gè)2xx響應收到以后，UAC core認為INVITE 事務(wù)完成了64*T1秒的定時(shí)。在這一時(shí)間點(diǎn)，所有沒(méi)有切換到已創(chuàng )建狀態(tài)的早期dialog都將結束。一旦認為INVITE 事務(wù)被UAC core完成， 則無(wú)更多新的2xx響應會(huì )到達。
如果，對INVITE確認了任何2xx響應，UAC core不想繼續那個(gè)dialog，然后，UAC必須發(fā)送一個(gè)BYE請求結束此dialog，處理方式在Section 15討論。
