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