13.3 UAS Processing
13.3.1 Processing of the INVITE
UAS core將會(huì )從事務(wù)層收到INVITE請求。它首先執行的是請求處理流程，參考Section 8.2，這個(gè)流程適用于內部請求和dialog的外部請求。
假設那些流程完成執行步驟沒(méi)有生成響應，此UAS core還會(huì )執行其他的步驟：
- 如果此請求是一個(gè)INVITE請求，這個(gè)INVITE請求包含一個(gè)Expires header的話(huà)，UAS core設置一個(gè)定時(shí)器，并且定時(shí)器時(shí)長(cháng)表示了header的值。當觸發(fā)定時(shí)器以后，這個(gè)請求會(huì )被認為超時(shí)。如果這個(gè)請求超時(shí)是在UAS已生成最終響應之前，487 (Request Terminated)響應應該被生成。
- 如果此請求是一個(gè)mid-dialog 請求的話(huà)，需要根據各自method獨立處理流程描述的來(lái)處理，具體的處理流程首先采用 Section 12.2.2。它也可能修改會(huì )話(huà)，Section 14 提供了更多細節。
- 如果請求在To header中有一個(gè)tag標簽，但是dialog identifier不能匹配任何已存dialogs，UAS 可能已經(jīng)崩潰，已重啟，或者不同的UAS可能收到了請求（可能是失敗的UAS）。在這種情況下，Section 12.2.2 提供了一個(gè)指南確保獲得一個(gè)穩定的處理流程。
從這里開(kāi)始的流程和后續的流程假設此INVITE是一個(gè)dialog外部的請求，并且其目的是為了創(chuàng )建一個(gè)新會(huì )話(huà)。
此INVITE可能包含一個(gè)會(huì )話(huà)描述，這種情況是UAS出現在一個(gè)這個(gè)會(huì )話(huà)的offer消息中。這是非常可能的，用戶(hù)已經(jīng)是那個(gè)會(huì )話(huà)中的一個(gè)參與方，甚至于此INVITE是一個(gè)dialog外部的INVITE。這種情況可以發(fā)生在多播會(huì )議，用戶(hù)被其他參與方邀請加入會(huì )議中。如果需要的話(huà)，此UAS可以在會(huì )話(huà)描述中使用 identifiers來(lái)檢測重復身份。
例如，SDP 包含一個(gè)會(huì )話(huà)ID和在origin (o)行的版本號。如果此用戶(hù)已經(jīng)是會(huì )話(huà)中的一員，并且包含了在會(huì )話(huà)描述的會(huì )話(huà)參數沒(méi)有任何改變，UAS 可以接受這個(gè)INVITE請求（發(fā)送一個(gè)2xx響應，無(wú)需提示此用戶(hù)）。
如果此INVITE沒(méi)有包含任何的會(huì )話(huà)描述，UAS最終被邀請加入一個(gè)會(huì )話(huà)中，并且UAC已經(jīng)被要求由UAS提供會(huì )話(huà)offer消息。此INVITE必須在它的第一個(gè)非失敗可靠性消息中提供此offer返回到此UAC端。在此規范中，就是一個(gè)對此INVITE的2xx響應消息。
UAS能夠指示處理狀態(tài)，接受，轉發(fā)和拒絕此邀請的能力。在這些所有場(chǎng)景中，UAS通過(guò)流程來(lái)構建一個(gè)響應消息，流程的處理方式參考Section 8.2.6。
13.3.1.1 Progress
如果UAS不能馬上應答請求的話(huà)，它可以選擇對UAC指示一些呼叫狀態(tài)（例如，指示電話(huà)正在振鈴）。這個(gè)指示狀態(tài)通過(guò)發(fā)送一些臨時(shí)響應來(lái)實(shí)現，臨時(shí)響應取值介于101和199之間。這些臨時(shí)響應創(chuàng )建早期的dialogs，因此需要遵從Section 12.1.1 章節的內容，和 Section 8.2.6章節的內容。一個(gè)UAS只要它愿意，它可以發(fā)送多個(gè)臨時(shí)響應。多個(gè)臨時(shí)響應中的每個(gè)臨時(shí)響應必須表示同一dialog ID。不過(guò)，這些響應不是可靠傳輸實(shí)現的。
如果UAS期望一個(gè)延遲時(shí)間來(lái)應答這個(gè)INVITE，它將需要請求一個(gè)拓展時(shí)間防止代理取消這個(gè)事務(wù)。當在一個(gè)事務(wù)中，響應之間的時(shí)間間隔超過(guò)三分鐘，代理有取消事務(wù)的選擇權。為了防止代理權限事務(wù)，UAS必須每分鐘發(fā)送一個(gè)非100的臨時(shí)響應來(lái)應對丟失臨時(shí)響應的可能性。
當用戶(hù)被執行了呼叫停靠或者配合PSTN網(wǎng)絡(luò )工作時(shí)（例如沒(méi)有應答呼叫，進(jìn)入了IVR流程），INVITE事務(wù)可以在這個(gè)拓展的時(shí)間段繼續執行下去。
13.3.1.2 The INVITE is Redirected
如果UAS決定轉發(fā)此呼叫時(shí)，需要發(fā)送一個(gè)3xx響應。一個(gè)300 (Multiple Choices)，301 (Moved Permanently)或302 (Moved Temporarily)應該包含一個(gè)Contact頭，這個(gè)contact頭包含一個(gè)或者多個(gè)新地址的URLs，這些新地址將會(huì )在
轉發(fā)呼叫中使用。這個(gè)響應被傳輸到INVITE服務(wù)器事務(wù)層，事務(wù)層處理它的重傳。
13.3.1.3 The INVITE is Rejected
經(jīng)常看到的場(chǎng)景是系統呼叫方不能啟動(dòng)或不能再進(jìn)行額外的呼叫。在這種狀態(tài)下，應該符合一個(gè)486 (Busy Here)。如果UAS知道，無(wú)任何系統端資源來(lái)接受呼叫時(shí)，一個(gè)600 (Busy Everywhere)響應應該被返回。但是，好像UAS知道這種情況，因此通常不會(huì )使用響應。響應被傳遞到INVITE 服務(wù)器端事務(wù)層，事務(wù)層將處理重傳流程。
UAS 應該返回一個(gè)488 (Not Acceptable Here)響應，實(shí)際上，UAS通過(guò)一個(gè)拒絕的offer來(lái)實(shí)現，這個(gè)offer包含在INVITE中。這樣的響應應該包括一個(gè)告警頭域值，這個(gè)值解釋offer被拒絕的原因。
13.3.1.4 The INVITE is Accepted
UAS core產(chǎn)生一個(gè)2xx響應消息。這個(gè)響應創(chuàng )建了一個(gè)dialog，因此按照Section 12.1.1 的處理流程來(lái)執行，另外還有Section 8.2.6流程。
對INVITE的一個(gè)2xx響應應該包含Allow頭和Supported頭，并且可能包含Accept 頭。包括這些頭的話(huà)，無(wú)需偵測UAS功能，在呼叫期間允許UAC決定UAS所提供的功能和其拓展。
如果INVITE請求包含一個(gè)offer消息，并且UAS還沒(méi)有發(fā)送answer消息的話(huà)， 2xx響應必須包含一個(gè)answer消息。如果此INVITE沒(méi)有包含offer消息的話(huà)，如果UAS還沒(méi)有發(fā)送offer的話(huà)，2xx 必須包含一個(gè)offer消息。
一旦響應構建后，響應會(huì )被傳遞到INVITE 服務(wù)器事務(wù)層。注意，INVITE 服務(wù)器事務(wù)收到最終響應，傳遞到傳輸層后，INVITE服務(wù)器事務(wù)將被銷(xiāo)毀。因此，直到ACK抵達之前，事務(wù)層定期直接發(fā)送響應消息到傳輸層是非常必要的。2xx響應被傳遞到傳輸層，同時(shí)攜帶一個(gè)定時(shí)器，定時(shí)器從T1秒開(kāi)始計算，然后針對每個(gè)重傳定時(shí)器時(shí)間翻倍計算，直到T1定時(shí)器時(shí)間設置到了T2秒。（T1和T2定義在Section 17）。當收到針對此響應的ACK請求后，響應重傳退出。這里，如何退出不取決于發(fā)送響應所使用的傳輸協(xié)議。
因為2xx通過(guò)端對端被重傳，因此，在UAS和UAC之間可能有多個(gè)hops，這些hops支持的UDP。為了保證經(jīng)過(guò)這些hops的可靠傳輸，盡管在UAS的傳輸是可靠性，響應消息也需要定期重傳。
如果在64*T1秒內，服務(wù)器端沒(méi)有收到ACK，服務(wù)器重發(fā)這個(gè)2xx響應，此dialog是被確認的，但是，此會(huì )話(huà)應該結束。結束會(huì )話(huà)使用BYE請求消息，具體描述在Section 15章節。
