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