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