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