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