當生成響應消息時，UAS不能直接期望使用拓展功能，除非在請求中的頭Supported頭中已經(jīng)表示支持了這個拓展。如果所希望的拓展不能被支持的話，服務器應該僅依賴基本的SIP和其他客戶端所支持的拓展來處理。在極少情況下，服務器沒有拓展的話就不能處理請求，這個服務器可以發(fā)送一個421（Extension Required）響應消息。這個響應消息表示，如果沒有具體的拓展功能，服務器端不能生成一個規(guī)范的響應。這些服務器端所需要支持的拓展必須包括在響應消息中的Require頭中。規(guī)范不推薦這種操作方式，因為，一般情況下，因為它會破壞流程的兼容性處理。

　　任何在non-421響應中列出的拓展功能必須包含在響應消息的Require頭列表中。

　　當然，服務器端也不能使用沒有在請求的Supported頭中列出的拓展。因此，響應消息中的 Require 頭就會只能包含在標準RFCs中多定義的可選標簽。

　　假設前面討論的所有子章節(jié)都通過的話，UAS的處理就會進入到和method相關的處理流程。Section 10 涵蓋REGISTER 請求，Section 11 涵蓋OPTIONS 請求，Section 13 涵蓋INVITE 請求，最后，Section 15 涵蓋BYE請求。

　　當UAS希望對請求構建一個響應時，UAS必須遵守一般的處理流程。這些處理流程會在下面的子章節(jié)中進行說明。另外，對于一些非常具體的響應碼的處理問題，這里沒有規(guī)范具體的細節(jié)，也可不做要求。

　　一旦所有和創(chuàng)建響應消息所關聯(lián)的流程完成以后，UAS負責返回到服務器事務層，這里是它收到請求的地址。

　　對生成響應來說，一個主要的不具體到某個method的原則是，UASs對非INVITE不應該發(fā)送臨時響應消息。相反，UASs應該盡快對非INVITE請求生成一個最終響應消息。

　　當生成100 （Trying）響應時，重新在在請求中的任何Timestamp頭必須拷貝到這個 100 （Trying）響應中。如果在生成響應時有延遲，UAS應該在Timestamp頭中添加一個延遲數(shù)值。這個延遲數(shù)值必須包含響應發(fā)送時間值和接收請求時間值，此值以秒為單位。

　　響應消息中的From必須和請求中的From頭相同。響應中的Call-ID頭必須和請求中的Call-ID相同。響應中的CSeq必須和請求中的CSeq相同。響應中的Via頭必須和請求中的Via頭相同，而且保持相同的順序。

　　如果在請求中包含了一個To tag標簽，響應中的To必須和請求中的To頭相同。但是，如果在請求中沒有包含To頭值，在響應中回復中，To頭中的URL必須和請求中To頭的URL相同；另外，在響應回復中，UAS必須在To標簽中增加一個標簽（支持100（trying）異常響應）。這樣處理的目的是確認UAS正在響應處理，也可能因為這個異常響應會生成一個dialog ID組件。同樣的標簽使用在此請求的所有響應中，包括最終響應和臨時響應（除了100（trying以外））。對此標簽生成的流程在中Section 19.3定義。

　　無狀態(tài)UAS是一種不保存事務狀態(tài)的UAS。它通常會轉發(fā)請求，而且協(xié)議發(fā)送后會丟棄UAS的狀態(tài)消息。 如果一個無狀態(tài)UAS收到請求重發(fā)，此UAS會重新生成響應，重新發(fā)送響應，就像它對第一個請求回復一樣。一個UAS不能是無狀態(tài)模式，除非這個method的請求處理總導致同樣的響應（如果請求是確認的）。無狀態(tài)注冊不遵守此規(guī)則。無狀態(tài)UASs不涉及事務層；UASs直接收到傳輸層請求后，直接對傳輸層返回響應。

　　無狀態(tài)UAS的基本功能是處理無需驗證的請求，這些請求面對響應問題。如果無驗證請求是通過有狀態(tài)UAS來處理的話，那么就會導致這些無驗證請求產生大量的事務狀態(tài)，這些事務狀態(tài)數(shù)據(jù)會導致在UAS端呼叫處理速度放慢，影響UAS處理性能，可能立刻生成了拒絕攻擊服務的條件。更多關于拒絕攻擊服務的內容，查閱Section 26.1.5。

　　無狀態(tài)UAS的最重要處理方式包括以下幾個方面：

　　關于其他方面的處理規(guī)范，無狀態(tài)UAS和有狀態(tài)UAS是一樣的。對每個新請求來說，UAS可以以有狀態(tài)方式或無狀態(tài)方式操作。

　　在一些技術架構中，代理服務器的目的是為了降低處理負載，這些代理服務器可能是負責處理路由請求和優(yōu)化信令路徑的強健性，都是通過重定向方式進行轉發(fā)處理。

　　重定向處理允許服務器端對請求在響應中推送路由消息，返回給客戶端，因此，重定向會把自己踢出此環(huán)路的事務處理中，定位到請求的目標地址。當請求發(fā)起方收到了重新定位響應以后，發(fā)起方會基于收到的URL地址重新發(fā)送一個新的請求。通過從網(wǎng)絡核心傳輸URLs到其網(wǎng)絡邊界，重定向允許相關網(wǎng)絡拓展性。

　　重定向服務器邏輯上由一個服務器事務層和一個事務用戶構成。事務用戶可以訪問某些定位服務（參考Section 10 獲得更多注冊和定位服務詳情）。定位服務實際上是一個數(shù)據(jù)庫，數(shù)據(jù)庫映射單個URL地址和一個或多個可選地址，這些地址是URL的目標地址。

　　重定向服務器自己不能發(fā)起任何屬于自己的SIP請求。收到了一個請求以后（除了CANCEL請求以外），服務器可以拒絕此請求或從定位服務收集可選地址，然后返回一個最終響應3xx。

　　對于格式非常規(guī)范的CANCEL請求，重定位服務器應該返回一個2xx響應。這個響應表示結束SIP事務處理。重定位服務器保持一個完整SIP事務的狀態(tài)。這是客戶端的責任，用來檢測介于重定向服務器之間的前轉環(huán)路。

　　當重定向服務器對請求返回一個3xx響應時，定向服務器會在Contact頭中插入查詢到的定位地址列表。 同時，在Contact頭中增加一個“expires”參數(shù)值，此值表示Contact數(shù)據(jù)中地址的生命周期。

　　Contact頭中包含URLs，并且提供新的地址和用戶名來嘗試，或者簡單提供指定的額外傳輸參數(shù)。301 （Moved Permanently）或302 （Moved Temporarily）響應可能也提供同樣地址和用戶名，這個用戶名是初始請求的目標地址，但是設定了額外的傳輸參數(shù)值，例如嘗試不同的服務器或組播地址，或者傳輸方式的相關，例如從UDP傳輸修改為TCP傳輸，或者相反處理。

　　不管怎樣，重定位服務器一定不能重定位一個請求到一個URL，這個URL和一個在Request-URI 的URL相同；相反，服務器可以代理轉發(fā)這個請求到目的地URL，或者拒絕此請求，返回一個404響應。

　　如果客戶端正在使用一個outbound proxy，并且重新定位此請求，這里可能產生一個潛在的無限重定位環(huán)路。

　　注意，一個 Contact頭可能涉及不同的源地址，而不是初始呼叫的源地址。例如，一個SIP呼叫連接到PSTN網(wǎng)關，網(wǎng)關可能需要提供一個特別的語音說明（例如，您撥打的號碼已經(jīng)被修改）。

　　一個Contact響應消息頭可以包含任何恰當?shù)腢RL值，這個值表示被呼叫方已經(jīng)被連接，也不僅局限于SIP URLs地址。例如，它可以包含電話的URLs地址，傳真或irc（如果有定義的話）或一個mailto: （RFC 2368 [32]） 郵件地址。Section 26.4.4 討論了 重定位處理中SIPs URL到一個non-SIPS URI的影響和局限性。

　　Contact頭中的“expires”參數(shù)表示URL的生命周期。此值以秒為單位計算。如果沒有提供此參數(shù)的話，以Expires頭中的數(shù)值決定URL的生命周期。如果出現(xiàn)異常值的話，此值應該視為等同于3600。

　　這種方式提供了一種最大程度的可能，保證了和RFC2534向后兼容，這也支持了一個在這個頭中的絕對時間值。如果收到了一個絕對時間的話，它將會被視為異常值，默認的時間為3600。

　　重定位服務器一定要忽略某些功能（包括無法識別的頭域格式，任何在Require中的未知可選標簽，甚至于未知的method名稱），和某些存在問題的重定位請求。

　　未完繼續(xù)……

　

　　　

　　關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享

　　Asterisk freepbx，F(xiàn)reeSBC技術文檔：www.freepbx.org.cn

　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產品：www.hiastar.com

　　Asterisk / FreePBX / FreeSBC中國合作伙伴，官方qq技術分享群（3000人）：589995817