13.3 UAS Processing

　　13.3.1 Processing of the INVITE

　　UAS core將會(huì)從事務(wù)層收到INVITE請(qǐng)求。它首先執(zhí)行的是請(qǐng)求處理流程，參考Section 8.2，這個(gè)流程適用于內(nèi)部請(qǐng)求和dialog的外部請(qǐng)求。

　　從這里開始的流程和后續(xù)的流程假設(shè)此INVITE是一個(gè)dialog外部的請(qǐng)求，并且其目的是為了創(chuàng)建一個(gè)新會(huì)話。

　　此INVITE可能包含一個(gè)會(huì)話描述，這種情況是UAS出現(xiàn)在一個(gè)這個(gè)會(huì)話的offer消息中。這是非�？赡艿�，用戶已經(jīng)是那個(gè)會(huì)話中的一個(gè)參與方，甚至于此INVITE是一個(gè)dialog外部的INVITE。這種情況可以發(fā)生在多播會(huì)議，用戶被其他參與方邀請(qǐng)加入會(huì)議中。如果需要的話，此UAS可以在會(huì)話描述中使用 identifiers來檢測重復(fù)身份。

　　例如，SDP 包含一個(gè)會(huì)話ID和在origin (o)行的版本號(hào)。如果此用戶已經(jīng)是會(huì)話中的一員，并且包含了在會(huì)話描述的會(huì)話參數(shù)沒有任何改變，UAS 可以接受這個(gè)INVITE請(qǐng)求（發(fā)送一個(gè)2xx響應(yīng)，無需提示此用戶）。

　　如果此INVITE沒有包含任何的會(huì)話描述，UAS最終被邀請(qǐng)加入一個(gè)會(huì)話中，并且UAC已經(jīng)被要求由UAS提供會(huì)話offer消息。此INVITE必須在它的第一個(gè)非失敗可靠性消息中提供此offer返回到此UAC端。在此規(guī)范中，就是一個(gè)對(duì)此INVITE的2xx響應(yīng)消息。

　　UAS能夠指示處理狀態(tài)，接受，轉(zhuǎn)發(fā)和拒絕此邀請(qǐng)的能力。在這些所有場景中，UAS通過流程來構(gòu)建一個(gè)響應(yīng)消息，流程的處理方式參考Section 8.2.6。

　　如果UAS不能馬上應(yīng)答請(qǐng)求的話，它可以選擇對(duì)UAC指示一些呼叫狀態(tài)（例如，指示電話正在振鈴）。這個(gè)指示狀態(tài)通過發(fā)送一些臨時(shí)響應(yīng)來實(shí)現(xiàn)，臨時(shí)響應(yīng)取值介于101和199之間。這些臨時(shí)響應(yīng)創(chuàng)建早期的dialogs，因此需要遵從Section 12.1.1 章節(jié)的內(nèi)容，和 Section 8.2.6章節(jié)的內(nèi)容。一個(gè)UAS只要它愿意，它可以發(fā)送多個(gè)臨時(shí)響應(yīng)。多個(gè)臨時(shí)響應(yīng)中的每個(gè)臨時(shí)響應(yīng)必須表示同一dialog ID。不過，這些響應(yīng)不是可靠傳輸實(shí)現(xiàn)的。

　　如果UAS期望一個(gè)延遲時(shí)間來應(yīng)答這個(gè)INVITE，它將需要請(qǐng)求一個(gè)拓展時(shí)間防止代理取消這個(gè)事務(wù)。當(dāng)在一個(gè)事務(wù)中，響應(yīng)之間的時(shí)間間隔超過三分鐘，代理有取消事務(wù)的選擇權(quán)。為了防止代理權(quán)限事務(wù)，UAS必須每分鐘發(fā)送一個(gè)非100的臨時(shí)響應(yīng)來應(yīng)對(duì)丟失臨時(shí)響應(yīng)的可能性。

　　當(dāng)用戶被執(zhí)行了呼叫�？炕蛘吲浜螾STN網(wǎng)絡(luò)工作時(shí)（例如沒有應(yīng)答呼叫，進(jìn)入了IVR流程），INVITE事務(wù)可以在這個(gè)拓展的時(shí)間段繼續(xù)執(zhí)行下去。

　　如果UAS決定轉(zhuǎn)發(fā)此呼叫時(shí)，需要發(fā)送一個(gè)3xx響應(yīng)。一個(gè)300 (Multiple Choices)，301 (Moved Permanently)或302 (Moved Temporarily)應(yīng)該包含一個(gè)Contact頭，這個(gè)contact頭包含一個(gè)或者多個(gè)新地址的URLs，這些新地址將會(huì)在

　　轉(zhuǎn)發(fā)呼叫中使用。這個(gè)響應(yīng)被傳輸?shù)絀NVITE服務(wù)器事務(wù)層，事務(wù)層處理它的重傳。

　　經(jīng)常看到的場景是系統(tǒng)呼叫方不能啟動(dòng)或不能再進(jìn)行額外的呼叫。在這種狀態(tài)下，應(yīng)該符合一個(gè)486 (Busy Here)。如果UAS知道，無任何系統(tǒng)端資源來接受呼叫時(shí)，一個(gè)600 (Busy Everywhere)響應(yīng)應(yīng)該被返回。但是，好像UAS知道這種情況，因此通常不會(huì)使用響應(yīng)。響應(yīng)被傳遞到INVITE 服務(wù)器端事務(wù)層，事務(wù)層將處理重傳流程。

　　UAS 應(yīng)該返回一個(gè)488 (Not Acceptable Here)響應(yīng)，實(shí)際上，UAS通過一個(gè)拒絕的offer來實(shí)現(xiàn)，這個(gè)offer包含在INVITE中。這樣的響應(yīng)應(yīng)該包括一個(gè)告警頭域值，這個(gè)值解釋offer被拒絕的原因。

　　UAS core產(chǎn)生一個(gè)2xx響應(yīng)消息。這個(gè)響應(yīng)創(chuàng)建了一個(gè)dialog，因此按照Section 12.1.1 的處理流程來執(zhí)行，另外還有Section 8.2.6流程。

　　對(duì)INVITE的一個(gè)2xx響應(yīng)應(yīng)該包含Allow頭和Supported頭，并且可能包含Accept 頭。包括這些頭的話，無需偵測UAS功能，在呼叫期間允許UAC決定UAS所提供的功能和其拓展。

　　如果INVITE請(qǐng)求包含一個(gè)offer消息，并且UAS還沒有發(fā)送answer消息的話， 2xx響應(yīng)必須包含一個(gè)answer消息。如果此INVITE沒有包含offer消息的話，如果UAS還沒有發(fā)送offer的話，2xx 必須包含一個(gè)offer消息。

　　一旦響應(yīng)構(gòu)建后，響應(yīng)會(huì)被傳遞到INVITE 服務(wù)器事務(wù)層。注意，INVITE 服務(wù)器事務(wù)收到最終響應(yīng)，傳遞到傳輸層后，INVITE服務(wù)器事務(wù)將被銷毀。因此，直到ACK抵達(dá)之前，事務(wù)層定期直接發(fā)送響應(yīng)消息到傳輸層是非常必要的。2xx響應(yīng)被傳遞到傳輸層，同時(shí)攜帶一個(gè)定時(shí)器，定時(shí)器從T1秒開始計(jì)算，然后針對(duì)每個(gè)重傳定時(shí)器時(shí)間翻倍計(jì)算，直到T1定時(shí)器時(shí)間設(shè)置到了T2秒。（T1和T2定義在Section 17）。當(dāng)收到針對(duì)此響應(yīng)的ACK請(qǐng)求后，響應(yīng)重傳退出。這里，如何退出不取決于發(fā)送響應(yīng)所使用的傳輸協(xié)議。

　　因?yàn)?xx通過端對(duì)端被重傳，因此，在UAS和UAC之間可能有多個(gè)hops，這些hops支持的UDP。為了保證經(jīng)過這些hops的可靠傳輸，盡管在UAS的傳輸是可靠性，響應(yīng)消息也需要定期重傳。

　　如果在64*T1秒內(nèi)，服務(wù)器端沒有收到ACK，服務(wù)器重發(fā)這個(gè)2xx響應(yīng)，此dialog是被確認(rèn)的，但是，此會(huì)話應(yīng)該結(jié)束。結(jié)束會(huì)話使用BYE請(qǐng)求消息，具體描述在Section 15章節(jié)。